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ABSTRACT 


This  document  describes  O/ana.  a  Descriptive  Intermediate  Attributed  Notation 
for  Ada.  being  both  an  introduction  and  reference  manual  for  it.  Diana  Is  an 
abstract  data  type  such  that  each  ob|ect  of  the  type  is  a  representation  of  an 
intermediate  form  of  an  Aoa  program.  Although  the  initial  uses  of  this  form  were 
for  communication  between  the  Front  and  Back  Ends  of  an  Ada  compiler.  It  Is 
also  intended  to  be  suitable  for  use  with  other  tools  in  an  Ada  programming 
environment. 

Diana  resulted  from  a  merger  of  the  best  properties  of  two  earlier  similar 
Intermediate  forms:  TOOL  and  AIDA. 
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PREFACE 


PREFACE  TO  THE  FIRST  EDITION 

This  document  defines  Diana,  an  Intermediate  form  of  ADA  [7]  programs  that 
is  especially  suitable  for  communication  betwoen  the  front  and  Back  Ends  of  Ada 
compilers.  It  Is  based  on  the  formal  definition  of  Ada  [6]  and  resulted  from  the 
merger  of  the  best  aspects  of  two  previous  proposals:  AIDA  (4.  10]  and 

TOOL  (21.  Although  Diana  Is  primarily  intended  as  an  interface  between  the  parts 
of  a  compiler.  It  Is  also  suitable  for  other  programming  support  tools  and 
carefully  retains  the  structure  of  the  original  source  program. 

The  definition  of  Diana  given  here  Is  expressed  In  another  notation.  IDL.  that 
is  formally  defined  in  a  separate  document  19].  The  present  document  is. 

however,  completely  self-contained:  those  aspects  of  IOL  that  are  needed  for  the 

Diana  definition  are  informally  described  before  they  are  used.  Interested  readers 
should  consult  the  IDL  formal  description  either  if  they  are  concerned  with  a 

more  precise  definition  of  the  notation  or  if  they  need  to  define  other  data 

structures  in  an  Ada  support  environment.  In  particular,  implementors  may  need 
to  extend  Diana  In  various  ways  for  use  with  the  tools  In  a  specific  environment, 
and  the  IDL  document  provides  Information  on  how  this  may  be  done. 

This  version  of  Diana  has  been  ‘frozen*  to  meet  the  needs  ot  several  groups 
who  require  a  stable  definition  in  a  very  short  timeframe.  We  invite  comments 
and  criticisms  for  a  longer-term  review.  We  expect  to  re-evaluate  Diana  after 
some  practical  experience  with  using  it  has  been  accumulated. 
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PREFACE  TO  THIS  EDITION 

Since  first  publication  of  the  Diana  Reference  Manual  In  March.  1981.  further 
developments  in  connection  with  Aoa  and  Diana  have  required  revision  of  Diana. 
These  developments  include  the  following: 

•  The  original  Diana  design  was  based  on  Aoa  as  defined  In  the  July 
1980  Aoa  Language  Reference  Manual  [7],  referred  to  hereafter  as 
Aoa-80:  the  present  revision  Is  based  on  Aoa  as  defined  In  the  July 
1982  Aoa  LRM  (81.  referred  to  hereafter  as  Ada-82. 

•  Experience  with  use  of  Oiana  has  revealed  errors  and  flaws  in  the 
original  design:  these  have  been  corrected. 

This  publication  reflects  our  best  efforts  to  cope  with  the  conflicting  pressures  on 
us  both  to  Impact  minimally  on  existing  Implementations  and  to  create  a  logically 
defensible  design. 

Tartan  Laboratories  Inc.  Invites  any  further  comments  and  criticisms  on  Diana 
in  general,  and  this  version  of  the  reference  manual  in  particular.  Any  cor¬ 
respondence  may  be  sent  via  ARPANet  mall  to  DIANA-QUERY0USC-ECL8.  Paper 
mail  may  be  sent  to 

Diana  Manual 

Tartan  Laboratories  Inc. 

477  Melwood  Avenue 
Pittsburgh  PA  15213 

We  believe  the  changes  made  to  Diana  make  no  undue  constraint  on  any 
Diana  users  or  potential  Diana  users,  and  we  wish  to  hear  from  those  who 
perceive  any  of  these  changes  to  be  a  problem. 
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CHAPTER  1 
INTRODUCTION 


The  purpose  of  standardization  Is  to 
aid  the  creative  craftsman,  not  to 
enforce  the  common  mediocrity  (111. 


In  a  programming  environment  such  as  that  envisioned  for  Ada1.  there  will  be 
a  number  of  tools— formatters  (pretty  printers),  language-oriented  editors,  cross- 
reference  generators,  test-case  generators,  and  the  like.  In  general,  the  Input 
and  output  of  these  tools  is  not  the  source  text  of  the  program  being  developed; 
Instead  it  is  some  intermediate  form  that  has  been  produced  by  another  tool  In 
the  environment.  This  document  defines  Diana.  Descriptive  Intermediate  At¬ 
tributed  Notation  for  Aoa.  Diana  is  an  intermediate  form  of  Aoa  programs  which 
has  been  designed  to  be  especially  suitable  for  communication  between  two 
essential  tools— the  Front  and  Back  Ends  of  a  compiler— but  also  to  be  suitable 
for  use  by  other  tools  in  an  Aoa  support  environment.  Diana  encodes  the  results 
of  lexical,  syntactic,  and  static  semantic  analysis,  but  it  does  not  include  the 
results  of  dynamic  semantic  analysis,  of  optimization,  or  of  code  generation. 

It  is  common  to  refer  to  a  scheme  such  as  Diana  as  an  intermediate 
representation  of  programs.  Olscussions  of  Diana,  including  those  in  this  docu¬ 
ment.  undoubtedly  use  this  and  similar  terminology.  Unfortunately,  too  often  the 
word  representation  suggests  a  concrete  realization  such  as  a  particular  data 
structure  in  primary  memory  or  on  a  file.  It  is  Important  for  the  reader  to  keep 
in  mind  that  Diana  does  not  imply  either  of  these.  Indeed,  quite  the  opposite  Is 
the  case;  it  was  carefully  defined  to  permit  a  wide  variety  of  realizations  as 
different  concrete  data  or  file  structures. 

A  far  more  accurate  characterization  of  Diana  Is  that  it  Is  an  abstract  data 
type.  The  Diana  representation  of  a  particular  AOA  program  Is  an  Instance  of 
this  abstract  type.  As  with  all  abstract  types.  Oiana  defines  a  set  of  operations 
that  provide  the  only  way  In  which  instances  of  the  type  can  be  examined  or 
modified.  The  actual  data  or  file  structures  used  to  represent  the  type  are 


1Ada  la  a  regiatered  Trademark  of  the  Ada  Joint  Program  Offtoe,  Department  of  Defenoe,  United 
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hidden  by  these  operations,  in  the  sense  that  the  implementation  of  a  private 
type  in  Aoa  is  hidden. 

We  often  refer  to  a  Diana  'tree',  'abstract  syntax  tree*,  or  'attributed  parse 
tree';  similarly,  we  refer  to  'nodes'  In  these  trees.  In  the  context  of  Diana  as 
an  abstract  data  type,  it  is  important  to  appreciate  what  /a  and  /a  not  implied  by 
such  terms.  We  are  not  saying  that  the  data  structure  used  to  implement  Diana 
is  necessarily  a  tree  using  pointers  and  the  like.  Rather,  we  are  using  the 
notion  of  attributed  trees  as  the  abatract  model  for  the  definition  of  Diana. 

An  abstract  data  type  consists  of  (a)  a  set  of  values  (the  domain  of  the 
type)  together  with  (b)  a  set  of  operations  on  those  values.  The  specification  of 
an  abstract  type  must  define  both  its  values  and  its  operations.  The  abstract 
modeling  method  of  specifying  an  abstract  type  provides  these  definitions  by 
defining  the  values  In  terms  of  some  mathematical  entity  with  which  the  reader  is 
presumed  to  be  familiar:  the  operations  of  the  type  are  then  defined  in  terms  of 

their  effect  on  the  modeling  entities.  in  the  case  of  Diana,  for  example,  the 

mathematical  model  is  that  of  attributed  trees.  The  reader  should  always  bear  in 
mind  that  the  trees  being  discussed  are  merely  conceptual  ones:  they  are  the 
model  of  the  values  in  the  Oiana  domain.  They  may  or  may  not  exist  as  an 
explicit  part  of  an  Implementation  of  the  Oiana  abstract  type2. 

1.1.  Design  Principles 

The  design  of  Diana  Is  based  on  the  collection  of  principles  that  are  dis¬ 
cussed  in  this  section.  As  with  any  design  intended  for  practical  use.  some 

compromise  of  these  principles  has  on  occasion  been  necessary.  The  frequency 
of  deviations  from  the  principles  is  extremely  low.  however,  and  an  understanding 
of  the  principles  will  help  the  reader  to  understand  Oiana. 

Section  1.1.1  presents  those  principles  that  motivated  the  original  design  of 
Diana,  and  Section  1.1.2  presents  those  principles  that  have  governed  changes 
made  since.  Section  1.1.3  defines  what  It  means  to  be  a  Diana  user  O.e. . 
producer  or  consumer)  and  Section  1.1.4  presents  a  lacuna  of  the  entire  Diana 
definition  effort. 


*An  aWomaOv*  dohnittonal  method,  algebraic  axiom*,  would  have  avoided  expttctt  referenoo  to  a  model 
avch  a*  tree*  and  henoo  might  have  been  leas  suggestive  of  an  implementation.  We  chose  not  to  uoe 
this  method  in  order  to  retain  a  dose  correspondent*  between  Oiana  and  Ada’s  formal  definition  [«]. 
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1.1.1.  Original  Design 

The  following  principles  governed  the  original  design  of  Diana: 

•  Diana  la  representation  Independent.  As  noted  above,  we  strove  to 
avoid  Implying  any  particular  implementation  strategy  for  the  Diana 
abstract  type.  For  example,  where  implementation-specific  infor¬ 
mation  is  needed  in  a  Oiana  representation  (such  as  values  on  the 
target-machine) .  we  make  reference  to  other  abstract  types  for 
representing  these  data:  each  implementation  is  expected  to  supply 
the  implementation  of  these  types.  In  addition,  we  strove  to  avoid 
any  implications  for  the  strategies  to  be  used  In  implementing  Front 
or  Back  Ends  of  compilers,  or.  for  that  matter,  any  other  environ¬ 
ment  tools.  Finally,  we  provide  an  explicit  mechanism  for  implemen¬ 
tations  to  extend  or  contract  the  Diana  form  in  a  consistent  manner  to 
cater  to  Implementation-specific  purposes. 

•  Oiana  la  baaed  on  Ada's  formal  definition  (6).  referred  to  hereafter  as 
the  AFD.  in  defining  an  Intermediate  representation  of  Ada.  we  face 
three  problems:  what  is  the  representation  of  a  particular  program, 
what  does  that  representation  mean  il.e. .  what  Is  the  semantics  of 
the  particular  instance  of  the  representational  scheme) .  and  when  is 
the  representation  conalatent  il.e..  meaningful)?  Since  the  AFD 
already  provides  the  latter  two  of  these3,  we  have  chosen  to  stay  as 
close  as  possible  to  the  definitional  scheme  used  there— particularly  to 
the  abstract  syntax.  Thus,  in  this  document  we  can  focus  exclusively 
on  the  first  of  these  questions,  namely  how  particular  programs  are 
represented. 

•  Regularity  la  a  principal  characteristic  of  Diana.  Regularity  of  descrip¬ 
tion  and  notation  was  a  principal  goal.  We  believe  that  this  regularity 
is  an  important  aspect  of  both  understanding  and  processing  a  Diana 
intermediate  form. 

•  Diana  must  be  efficiently  Implementable.  As  noted  above.  Diana  Is 

beat  viewed  as  an  abstract  data  type.  Its  specification  is  more 

abstract  than  Is  directly  supported  by  current  programming  languages. 
Including  Aoa.  Nonetheless.  Diana  Is  Intended  to  be  usedi  Hence.  It 
Is  essential  that  there  exist  an  efficient  Implementation  of  It  (or 
actually,  several  different  efficient  implementations  of  It)  in  contem¬ 
porary  languages— especially  Aoa  itself.  Later  chapters  deal  with  this 
issue  explicitly;  for  now.  the  Important  point  is  that  Implementability 
was  a  primary  consideration  and  that  such  Implementations  do  exist. 

•  Consideration  of  the  kinds  of  processing  to  be  done  Is  paramount. 
Although  the  primary  purpose  of  Diana  Is  communication  between  the 
Front  and  Back  Ends  of  compilers,  other  environment  tools  will  use  it 


3Somo  proWwiw  with  the  AFD  as  an  anamar  to  thooo  quorttono  «  MOrteN  to  Soetton  1.1.4  on 
page  14. 
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as  wall.  The  naads  of  such  programs  wars  considered  carafully. 
Thay  influancad  a  number  of  tha  Oiana  design  decisions.  Including  the 
following: 

•  W*  define  two  trees— an  Abstract  Syntax  Tree  constructed  prior 
to  semantic  analysis  (see  Appendix  II).  and  an  attributed  tree 
(tha  Diana  structure)  constructed  as  a  result  of  static  semantic 
analysis.  These  two  structures  are.  of  course,  closely  related. 
By  defining  both  of  them,  we  extend  the  applicability  of  Oiana  to 
Include  those  tools  that  need  only  the  parsed  form. 

•  We  considered  the  size  of  (various  implementations  of)  Diana 
representations,  and  we  made  careful  tradeoffs  between  this  si zb 
and  processing  speed.  We  envision  that  at  least  some  Ada 
support  environments  will  be  implemented  on  small  computing 
systems:  hence,  we  considered  It  essential  that  Diana  be  usable 
on  these  systems. 

•  We  never  destroy  the  structure  of  the  original  source  program: 
except  for  purely  lexical  Issues  ( such  as  the  placement  of 
comments) .  it  Is  always  possible  to  regenerate  the  source  text 
from  its  Diana  form.  See  Appendix  III. 

•  We  permit  the  possibility  of  extending  the  Diana  form  to  allow  the 
inclusion  of  information  for  other  kinds  of  processing.  Of  par¬ 
ticular  concern,  for  example,  are  extensions  to  encode  infor¬ 
mation  needed  by  various  optimization  and  code-generation 
strategies. 

•  In  Diana,  thara  la  a  single  definition  of  each  Ada  entity.  Each  defin¬ 
able  entity,  e.g.  variable,  subprogram,  or  type,  is  represented  by  a 
single  defining  occurrence  in  OtANA.  Uses  of  the  entity  always4  refer 
to  this  defining  occurrence.  Attributes  at  this  definition  point  make  It 

;  possible  for  all  information  about  the  entity  to  be  determined.  Thus. 

}  although  the  defining  occurrences  are  part  of  the  program  tree,  the 

i  set  of  them  plays  the  same  role  as  a  dictionary  or  symbol  table  in 

conventional  compiler  terminology5. 

•  Diana  must  respond  to  the  Issues  posed  by  Ada's  separate 
compilation  facility.  It  Is  not  in  the  domain  of  Diana  to  provide  the 
library  management  upon  which  separate  compilation  of  Aoa  is  based. 
Nonetheless,  the  possibility  of  separate  compilation  affects  the  design 


*fhete  to  a  angle  exception:  Private  types  use  a  different  defining  occurrence  for  references  inside 
the  package  body  in  which  they  ere  defined  than  they  do  elsewhere.  See  Section  3.S.1.2  on  page 
10S. 


fIMwf  W  1  uiw  Bn  nl^NBnlBnwRIOn  PoSaffy  'Wwi  W  eB^Ww  WfB^B  vBIWnf^  WtAAnTV^We  W1W( 

■  —  Itoasi  MsasssMsksa  MeMeS  Im  aeeessAeki  MWiSftiled  uMlSe 

lef  ulBy  nmy  DB  UlB  faWy  Wit!  Of  urB  iBfaB^wlwDOfl  JnBPPnl  iwi  IBBIIt 

each  knpfeinontatlone  are  ocmpto^y  consistent  with  the  Diana  philosophy-  Other  implementation  options 
ere  diccmscd  in  Chapter  S. 


Introduction 


Section  1.1.1  /  Page  11 


ot  Diana  in  two  ways: 

*  The  possibility  ot  separate  compilation  places  certain  restrictions 
on  Diana  and  requires  the  possibility  of  certain  Indirect 
references.  We  take  care,  for  example,  never  to  require  for¬ 
ward  references  to  entitles  whose  definition  may  be  separately 
compiled. 

*  We  recognize  that  many  library  systems  may  wish  to  store  the 
Diana  form  of  a  compilation  unit— in  order  to  support  optimization 
across  compilation  units,  for  example.  Various  design  decisions 
in  Diana  were  Influenced  by  this  possibility. 

•  There  must  be  at  I east  one  form  of  the  Dfana  representation  that  can 
be  communicated  between  computing  systems.  We  have  defined  in 
Chapter  5  an  externally  visible  ASCII  form  of  the  Diana  representation 
of  an  Aoa  program.  In  this  form,  the  Oiana  representation  can  be 
communicated  betweon  arbitrary  environment  tools  and  even  between 
arbitrary  computing  systems.  The  form  may  also  be  useful  during  the 
development  of  the  environment  tools  themselves. 


1.1.2.  Principles  Governing  Changes 

The  design  principles  just  listed  that  governed  the  original  design  of  Diana 
have  been  augmented  during  this  phase  of  modification  by  additional  principles. 
It  is  important  that  these,  too.  be  documented. 

•  Diana  will  be  changed  only  when  something  Is  sufficiently  wrong  that  It 
requires  change.  We  state  this  metric  despite  the  fact  It  is  such  a 
broad  characterization  that  deciding  when  something  Is  'sufficiently 
wrong’  is  clearly  judgmental.  Nonetheless,  the  principle  has  utility. 

For  example.  It  implies  that  we  not  make  cosmetic  changes,  no 
matter  how  obvious  it  might  be  that  the  change  would  result  in  a 
better  product.  Our  motto:  'If  it’s  not  broken,  don’t  fix  it.’ 

•  We  do  not  unduly  Impact  existing  Diana  users.  Thus  we  refrain  from 
changes  whose  Impact  on  existing  implementations  significantly  ex¬ 
ceeds  anticipated  future  benefits.  Of  course,  changes  with  a  large 
enough  savings  down  the  road  may  be  made  even  if  doing  so  affects 
current  implementations.  Again,  there  Is  a  judgmental  call  here. 

•  It  Is  often  necessary  to  make  some  decision,  in  several  cases,  either 
of  two  or  more  ways  to  proceed  has  seemed  equally  plausible,  and 
we  have  been  unable  to  determine  any  significant  advantage  to  any 
decision.  Nonetheless.  In  such  cases  we  have  made  a  decision, 
since  we  judge  a  slightly  incorrect  decision  to  be  better  for  the  Diana 
community  than  no  decision.  At  least,  there  is  a  standard  way  for 
Diana  users  to  to  proceed. 

•  Where  possible  we  have  presented  the  style  ot  the  original  Diene 
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design.  Stylistic  concerns  Include  such  Issues  as  creating  IOL  classes 
for  attributes,  preserving  the  same  naming  conventions,  and  so  on. 

•  Diana  does  not  unnocasaarily  deviate  from  Ada's  formal  daflnltlon. 

Even  though  the  formal  definition  effort  apparently  Is  no  longer  being 
actively  pursued*,  we  continue  to  adhere  to  its  style. 

Unfortunately  the  guidelines  Just  presented  and  those  of  the  previous  section 
are  sometimes  In  conflict.  For  example,  consider  a  minor  Inconsistency  found 
In  the  original  design.  The  principle  of  conalatoncy  might  suggest  a  change, 
while  the  principle  of  sufficiently  wrong  might  suggest  leaving  It  alone.  What  we 
have  done  Is  to  be  reasonable  In  considering  changes.  Diana  Is  Intended  to  be 
used,  and  we  continue  to  strive  to  Keep  Diana  responsive  to  the  needs  of  Its 
users. 


1.1.3.  What  Is  a  'Diana  User' 

Inasmuch  as  Duma  Is  an  abstract  data  type,  there  Is  no  need  that  It  be 
Implemented  In  any  particular  way.  Additionally,  bocause  Diana  Is  extendable,  a 
particular  Implementation  may  choose  to  use  a  superset  of  the  Diana  defined  In 
this  DRM.  In  the  face  of  Innumerable  variations  on  the  same  theme,  wo  foel  It 

is  appropriate  to  offer  a  definition  of  what  It  means  to  use  Diana.  Since  It 

makes  sense  to  consider  Diana  only  at  the  interfaces,  it  Is  appropriate  to 

consider  two  types  of  Oiana  users:  those  which  produce  Diana,  and  those  which 
consume  it7.  In  addition,  some  implementations  ( particularly  compilers)  may 
claim  to  employ  Diana  as  an  Intermediate  form,  even  though  neither  Interface  to 
external  Diana  Is  provided.  We  consider  these  three  aspects  In  turn: 

producer  In  order  tor  a  program  to  be  considered  a  Diana  producer.  It 

must  produce  as  output  a  structure  that  Includes  all  of  the 
Information  contained  In  Diana  as  defined  In  this  document. 
Every  attribute  defined  herein  must  be  present,  and  each  attribute 
must  have  the  value  defined  for  correct  Diana  and  may  not  have 
any  other  value.  This  requirement  means,  for  example,  that 
additional  values,  such  as  the  evaluation  of  non-static  expres¬ 

sions.  may  not  be  represented  using  the  DiANA-deflned  attributes. 
An  Implementation  is  not  preventod  from  defining  additional  at¬ 
tributes.  and  In  fact  it  is  expected  that  most  Diana  producers  will 


*The  formal  daftnttton  l«  booed  on  Ado-SO,  and  there  la  no  visible  Intent  to  upgrade  It  to  Ada-SE. 

7Theee  are  not  mutually  eaduatve;  tor  example,  a  oompHor  Front  End  that  prodwoeo  Diana  may  aloe 
read  Diana  tor  aoparate  compilation  purposes. 
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also  produce  additional  attributes. 

There  Is  an  additional  requirement  on  a  Diana  producer:  The 
Oiana  structure  must  have  the  property  that  It  could  have  been 
produced  from  a  legal  Ada  program.  This  requirement  Is  likely 
to  Impinge  most  strongly  on  a  tool  other  than  a  compiler  Front 
End  that  produces  Diana.  As  an  example  of  this  requirement.  In 
an  arithmetic  expression,  an  offspring  of  a  multiplication  could 
not  be  an  addition  but  would  Instead  have  to  be  a 
parenthesized  node  whose  offspring  was  the  addition,  since  Ada's 
parsing  rules  require  the  parentheses.  The  motivation  for  this 
requirement  Is  to  ease  the  construction  of  a  Diana  consumer, 
since  the  task  of  designing  a  consumer  is  completely  open-ended 
unless  it  can  make  some  reasonable  assumptions  about  its  input. 

c onsumer  in  order  for  a  program  to  be  considered  a  Diana  consumer.  It 

must  depend  on  no  more  than  Diana  as  defined  herein.  This 

restriction  does  not  prevent  a  consumer  from  being  able  to  take 
advantage  of  additional  attributes  that  may  be  defined  in  an 
implementation;  however,  the  consumer  must  also  be  able  to 
accept  Input  that  does  not  have  these  additional  attributes.  It  is 

also  incorrect  for  a  program  to  expect  attributes  defined  herein  to 

have  values  that  are  not  here  specified.  For  example,  it  is 

wrong  for  a  program  to  expect  the  attribute  sm_value  to  contain 
values  of  expressions  that  are  not  static. 

employer  The  definition  of  a  Diana  employer  Is  more  difficult.  The  Intent  Is 
that  the  Intermediate  form  must  be  close  to  Diana;  the  problem  is 
that  we  have  no  useful  metric  for  close.  In  addition,  the  lack  of 
a  visible  external  representation  of  the  intermediate  form  ap¬ 
parently  precludes  application  of  any  validation  procedure.  This 
point  is  addressed  further  below. 

There  are  two  attributes  that  are  defined  herein  that  are  not  required  to  be 
supported  by  a  Diana  user:  lx_comments  and  lx..srcpos.  We  believe  that  these 
attributes  are  too  implementation  specific  to  be  required  for  all  Diana  users. 

It  is  instructive  to  examine  the  problems  suggested  above  of  defining  a  Diana 
employer.  Inasmuch  as  papers  have  begun  to  appear  in  the  literature  in  which 
a  given  Implementation  claims  'to  use  Diana'  or  'to  be  DiANA-like'.  we  feel  that 
It  is  appropriate  to  offer  a  metric  against  which  to  |udge  such  claims.  Consider 
the  following  three  candidates  for  such  a  metric: 

•  A  representation  can  properly  be  called  Diana  If  It  contains  all  the 
same  information  that  Diana  contains. 

•  A  representation  can  properly  be  called  Diana  If  one  can  provide  a 
reader/writer  for  transforming  between  the  representation  and  Diana. 


__  I'-*  -  >  -  • 
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•  A  representation  can  properly  be  called  Diana  If  It  provides  a  package 
equivalent  to  the  one  described  In  Chapter  4  for  accessing  and 
modifying  the  structure. 

Although  the  first  two  definitions  have  a  certain  appeal.  It  is  unfortunately  true 
that  neither  of  them  Is  at  all  adequate,  since  a  little  thought  reveals  that  the 
original  Ada  source  text  meets  either  requirement.  One  repair  possibility  is  to 
attempt  to  tighten  up  the  second  definition  by  restricting  the  reader/writer  to  be 
'simple'.  In  some  sense,  but  defining  that  sense  appears  to  require  Solomonic 
wisdom. 

The  third  definition  also  has  appeal,  though  It  Is  again  hard  to  use  as  a 
metric  If  the  external  Interface  Is  not  actually  provided  in  a  useful  way. 

It  is  our  opinion  that  It  Is  not  proper  to  claim  that  a  given  Implementation 
uses  Diana  unless  either  It  meets  the  following  two  criteria: 

•  It  must  be  able  to  read  and/or  write  (as  appropriate)  the  external 
form  of  Diana  defined  In  Chapter  5  of  this  document. 

•  That  Diana  must  meet  the  requirements  of  a  Oiana  producer  or 
consumer  as  specified  In  this  section. 

or  it  meets  this  criterion: 

•  The  Implementation  provides  a  package  equivalent  to  that  described  In 
Chapter  4. 

We  hope  that  writers  of  papers  will  give  consideration  to  this  discussion. 

1.1.4.  Specification  of  Diana 

An  Important  problem  faced  by  new  users  of  Diana  is  to  determine,  for  any 
particular  Ada  construct,  just  what  Oiana  Is  to  be  produced  from  It.  Although  the 
Diana  specification  in  Chapter  2  specifies  precisely  what  nodes  must  exist,  which 
attributes  each  node  must  contain,  and  what  type  the  value  of  each  attribute 
must  have,  it  often  says  very  little  about  what  value  the  attribute  Is  to  have. 

This  problem  is  addressed  In  this  document  In  several  ways.  Often,  com¬ 
ments  appear  In  Chapter  2  specifying  or  suggesting  the  Intended  value.  In 
addition,  the  lengthy  discussion  of  design  rationale  in  Chapter  3  presents  much 
additional  information.  Unfortunately,  still  more  help  Is  needed,  and  a  complete 
solution  to  the  problem  of  providing  such  help  is  beyond  the  capability  of  this 
document.  The  remainder  of  this  section  Is  speculation  about  the  form  such 
help  might  take. 
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What  Is  needed  Is  Is  a  formal  way  to  determine,  given  an  Ada  source  text 
and  a  Diana  structure  purported  to  be  a  correct  representation  of  the  source, 
whether  or  not  the  Diana  Is  In  fact  correct.  For  example,  suppose  that  a  Is 
some  Ada  text  and  that  0  purports  to  be  a  Diana  representation  of  it.  Needed  is 
a  predicate  n  such  that 
jr(a,  0) 

Is  true  If.  and  only  If.  0  correctly  represents  a. 

Ideally,  the  structure  of  ir  should  be  such  that  It  Is  accessible  to  a  human 
reader  who  requires  help  In  designing  an  Aoa  front  end  or  other  transformer 
from  ADA  to  Oiana.  No  such  predicate  now  exists.  The  kinds  of  questions  that 
such  a  predicate  should  help  to  answer  include  the  following: 

1.  Is  a  given  abstract  syntax  tree  (AST)  correct  for  a  given  Ada 
program? 

2.  What  should  be  the  value  of  each  semantic  attribute  in  a  Diana 
structure? 

3.  When  Is  sharing  permitted  In  the  AST? 

4.  May  the  same  node  appear  In  several  sequences? 

We  believe  that  one  way  to  meet  these  needs  Is  by  first  specifying  the 
transformation  from  Aoa  to  AST  and  then  defining  a  predicate,  say  ir,  on  ASTs 
and  Diana  such  that  for  an  AST  r  and  a  Diana  structure  0  the  predicate 
n,iT,  0) 

returns  true  If  the  Diana  structure  0  Is  a  correct  representation  of  the  AST  r. 
This  dichotomy  appears  useful. 

Translation  of  Ada  source  to  abstract  syntax  tree  (AST)  Is  a  two-step 
process: 

•  Translation  of  Ada  source  to  parse  tree  (PT).  The  latter  Is  a  tree  in 
which  each  node  is  labeled  with  the  name  of  a  non-terminal  from 
Ada’s  BNF  definition  and  has  as  many  offspring  as  clauses  appear  In 
the  relevant  definition  of  that  non-terminal.  Given  a  non-amblguous 
BNF  tor  Ada.  such  a  tree  is  uniquely  defined.  Although  the  BNF  in 
Ada's  LRM  Is  ambiguous.  It  Is  not  difficult  to  create  a  non-amblguous 
version  that  preserves  all  essential  structure. 

•  Translation  of  PT  to  AST.  This  step,  though  somewhat  harder  to 
specify  than  the  previous  one.  Is  not  conceptually  difficult. 


We  believe  It  Is  possible  to  describe  the  PT  to  AST  transformation  by  using 
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an  attribute  grammar  to  specify  the  AST  as  an  attribute  of  the  root  of  the  FT. 
The  specification  of  the  AST  to  Diana  transformation  (Including  specification  of  the 
semantic  attributes)  Is  a  much  harder  problem  and  Is  still  open.  We  are 
exploring  methods  of  attacking  these  problems. 


1.2.  Structure  of  the  Document 

Abstractly,  an  Instance  of  the  Diana  form  of  an  Aoa  program  Is  an  attributed 
tree.  The  tree's  structure  is  basically  that  of  the  abstract  syntax  tree  defined  in 
the  AFO.  Attributes  of  the  nodes  of  this  tree  encode  the  results  of  semantic 
analysis.  Operations  defined  on  the  Diana  abstract  data  type  (see  Chapter  4) 
provide  the  predicates,  selectors,  and  constructors  required  to  manipulate  this 
tree  and  its  attributes.  The  structure  of  this  document  reflects  the  several  facets 
of  the  Diana  definition. 

•  First  we  define  precisely  the  domain  of  the  Diana  data  type.  We  do 
so  by  specifying  the  set  of  abstract  trees,  their  attributes,  and  various 
assertions  about  them  (which  actually  appear  as  comments) .  This 
definition  is  done  in  two  steps: 

*  in  Section  1.4  we  describe  the  notation,  called  IDL.  for  exhibit¬ 
ing  Diana's  definition. 

•  In  Chapter  2.  we  use  the  notation  to  define  the  actual  trees  and 
attributes8. 

•  Second,  we  provide  a  rationale  for  some  of  the  more  subtle  design 
decisions—  particularly  with  respect  to  the  attributes  of  nodes  In  the 
abstract  tree.  This  rationale  appears  In  Chapter  3. 

•  Third,  we  define  the  oparatlona  on  the  Diana  abstract  type.  This 

definition  appears  In  Chapter  4.  and  again  is  done  in  two  steps. 

First,  we  describe  generlcally  the  nature  of  these  operations. 
Second,  we  show  how  these  operations  can  be  realized  In  conven¬ 
tional  programming  languages  by  showing  how  an  Interface  can  be 
derived  from  the  Diana  definition  and  by  showing  the  specification  part 
(except  for  the  private  part)  of  an  Aoa  package  that  specifies  Just 
such  an  Interface.  We  also  show  here  how  the  interface  is  altered 
when  additional  attributes  or  nodes  are  Introduced9. 


State  that  a  parttouler  implementation  may  da Ann  an  extended  domain  (additional  attribute*) .  What 
wi  tfiflM  hift  Is  i  did  icto^udt  nt> 

that  an  Implementation  may  dottne  additional  operations.  Again,  we  merely  define  a  required 
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•  Fourth.  In  Chapter  5.  we  define  a  canonical  way  to  represent  Diana 
structures  external  to  a  computer. 

•  Finally.  In  Chapter  6.  we  discuss  Implementation  issues  and  Illustrate 
some  of  the  various  options  that  are  available. 

There  are  also  six  appendices.  Appendix  I  provides  the  definition  of  the 
predefined  environment  for  Aoa  compilations.  In  Appendix  II  we  define  the 
Abstract  Syntax  Tree  from  the  AFO  as  a  derivative  of  the  Oiana  representation. 
Appendix  III  describes  how  the  source  of  an  Ada  program  can  be  regenerated 
from  the  Duma  representation  and  Includes  a  discussion  of  the  normalizations  of 
reconstructed  source  programs  Imposed  by  Diana. 

Appendices  IV.  V.  and  VI  provide  three  summaries  of  the  Oiana  definition. 
These  summaries  provide  an  Invaluable  cross  reference  Into  the  main  definitions 
and  should  be  an  important  aid  to  the  reader. 

There  Is  an  extensive  Index  that  lists  separately  topics.  Diana  attributes,  and 
Diana  node  names. 

1.3.  Attribution  Principles  of  Diana 

This  section  describes  the  general  principles  used  to  decide  on  the  details  of 
Oiana.  A  more  detailed  rationale  Is  given  In  Chapter  3. 

The  design  of  an  Intermediate  representation  Involves  deciding  what  infor¬ 
mation  to  represent  explicitly  and  what  information  to  recompute  from  the  stored 
Information.  There  are  two  extreme  positions  one  can  lake: 

•  The  source  program  (or  its  abstract  syntax  tree)  contains  all  the 
necessary  information:  other  Information  can  be  recomputed  when 
necessary. 

•  All  Information  which  can  be  computed  should  be  computed  and  stored 
within  the  Intermediate  representation. 

Duma's  underlying  principles,  which  are  a  compromise  between  these  extrema, 
can  be  derived  from  Duma's  Intended  role  In  an  Aoa  Program  Support  Environ¬ 
ment  (APSE)  (3).  We  envisage  Duma  as  created  by  an  Aoa  Front  End.  used  as 
input  to  that  Front  End  for  separate  compilation  purposes,  used  as  Input  to  the 
compiler's  Back  End.  and  used  (produced  or  consumed)  by  a  variety  of  other 
tools  of  the  APSE. 

For  all  these  tools  Duma  should  contain  Information  that  is  both  sufficient  and 
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approprlat *.  There  are  two  questions  relevant  to  deciding,  about  a  given 

attribute,  whether  or  not  to  Include  it  in  the  Diana: 

•  Does  the  Information  the  attribute  contains  belong  in  the  Intermediate 
representation? 

•  Should  the  Information  be  represented  explicitly,  or  should  It  be 
recomputed  from  the  stored  Information? 

We  have  used  two  criteria  In  deciding  of  a  given  attribute  whether  or  not  to 
Include  It: 

•  Diana  should  contain  only  such  Information  as  would  be  typically  dis¬ 
covered  via  static  (as  opposed  to  dynamic)  semantic  analysis  of  the 
original  program. 

•  If  Information  can  be  easily  recomputed,  it  should  be  omitted. 

These  two  points  are  discussed  at  length  In  the  following  two  subsections. 

First,  however,  a  point  must  be  made.  Although  the  original  Diana  design 
used  the  metric  of  ease  of  computation  in  deciding  what  attributes  to  include, 
the  concept  has  been  considerably  expanded  In  revisions  of  Diana  and  of  this 
report.  As  a  result,  attributes  now  exist  in  Diana  which,  according  to  this 
criterion,  ought  not  to  be  there.  We  have  elected  to  let  them  remain  for  two 
reasons:  They  are  not  sufficiently  wrong  to  require  fixing,  and  their  removal 
would  likely  unduly  Impact  existing  Oiana  users.  Note  that  these  are  the  first  twe 
principles  enunciated  In  Section  1.1.2  on  page  1 1 . 


1.3.1.  Static  Semantic  Information 

We  believe  that  It  Is  appropriate  for  Diana  to  Include  only  that  Information  that 
Is  determined  from  static  semantic  analysis,  and  that  Diana  should  exclude 
Information  whose  determination  requires  dynamic  semantic  analysis. 

This  decision  affects  the  evaluation  of  non-static  expressions  and  evaluation  of 
exceptions.  For  example,  the  attribute  sm_yalua  should  not  be  used  to  hold  the 
value  of  an  expression  that  is  not  static,  even  if  an  Implementation's  semantic 
analyzer  is  capable  of  evaluating  some  such  expressions.  Similarly,  exceptions 
are  part  of  the  execution  </.*. .  dynamic)  semantics  of  Ada  and  should  not  be 
reprosonted  In  Oiana.  Thus  the  attribute  sm_va/ue  Is  no  longor  used  to 
represent  an  exception  to  be  raised,  as  it  was  In  an  earlier  version  of  Diana. 

Of  course,  an  implementation  that  does  compute  these  additional  values  may 
record  the  Information  by  defining  additional  attributes.  However,  any  Diana 
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consumer  that  relies  on  these  attributes  cannot  be  considered  a  correct  Diana 
'user',  as  defined  In  Section  1.1.3  on  page  12. 

1.3.2.  What  Is  'Easy  to  Recompute'? 

Part  of  the  criteria  for  Including  an  attribute  In  Diana  Is  that  It  should  be 
omitted  if  it  is  easy  to  recompute  from  the  stored  Information.  We  feel  it  is 
Important  to  avoid  such  redundant  encodings  if  Diana  Is  to  remain  an  usefully 
Implementable  internal  representation.  Of  course  this  guideline  requires  that  we 
define  this  phrase,  and  we  suggest  that  an  attribute  Is  easily  computed  if 

•  It  requires  visits  to  no  more  than  three  to  four  nodes;  or 

•  It  can  be  computed  In  one  pass  through  the  Diana  tree,  and  all 
nodes  with  this  attribute  can  be  computed  in  the  same  pass. 

The  first  criterion  is  clear:  the  second  requires  discussion. 

Consider  first  an  attribute  that  is  needed  by  a  compiler  front  end  (FE)  to  do 
semantic  analysis.  As  the  FE  does  Its  work,  it  is  free  to  create  extra 
( non— Diana)  attributes  for  Its  purposes.  Thus  the  desired  attributes  can  be 
created  by  those  who  need  them.  To  require  them  Is  an  imposition  on 
implementations  which  use  algorithms  that  do  not  require  these  particular 
pointers.  If  we  add  every  attribute  that  anyone  requires,  everyone  will  be 
overwhelmed. 

Consider  now  an  attribute  needed  by  a  back  end  (BE)  to  do  code  genera¬ 
tion.  As  long  as  the  attribute  can  be  determined  in  a  single  pass,  the  routine 
that  reads  In  the  Diana  can  readily  add  it  as  it  reads  in  the  Diana.  Again,  some 
implomentors  may  not  need  the  attribute,  and  It  is  inappropriate  to  burden 
everyone  with  it. 

It  Is  for  these  reasons  that  we  have  rejected  suggestions  for  pointers  to  the 
enclosing  compilation  unit,  pointers  to  the  enclosing  namescope.  and  back 
pointers  in  general.  These  are  attributes  that  are  easily  computed  in  one  pass 
through  the  Diana  tree  and  Indeed  may  not  be  needed  by  all  implementations. 

Of  course,  a  Diana  producor  can  cro8te  a  structure  with  extra  attributes 
beyond  those  specified  for  Diana.  Nevertheless,  any  Diana  consumer  that  relies 
on  these  additional  attributes  Is  not  a  Diana  user,  as  that  concept  Is  defined  in 
Section  1.1.3  on  page  12. 
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1.3.3.  Other  Principles 

There  are  other  reasons  why  particular  classes  of  attributes  are  present  in 
Diana. 

•  A  tree-like  representation  of  the  source  program  is  well-suited  for 
many  of  the  tools  that  will  exist  In  an  APSE,  such  as  semantic 
analyzers,  optimizers,  and  syntax-directed  editors.  The  tree  structure 
Is  represented  In  Diana  via  the  structural  attributes;  we  use  the  same 
abstract  syntax  tree  as  given  by  the  AFO.  with  a  few  differences 
described  In  Section  3.  1  on  page  80. 

•  Lexical  attributes  (such  as  symbol  and  literal  representations  and 
source  positions)  are  needed  by  the  compiler  (e.g. .  for  error 
messages) .  They  are  also  useful  to  other  APSE  tools  for  referring 
back  to  the  source  or  for  regenerating  source  text  from  the  inter¬ 
mediate  representation . 

•  Ada  provides  the  attribute  'SIZE  to  determine  the  minimum  number  of 
bits  needed  to  represent  some  ob)ect  or  subtype.  if  this  attribute  is 
applied  to  a  static  type,  the  result  is  static  and  is  therefore  required 
by  Ada's  semantics  to  be  known  at  compile  time.  It  represents  a 
target-machine  •  property  properly  computed  by  a  code  generator. 
However,  as  it  can  be  used  In  static  expressions,  the  Front  End  must 
know  its  value  in  some  contexts.  For  example,  the  selection  of  a 
base  type  for  a  derived  integer  type  depends  on  a  range  constraint. 
Without  this  information,  the  semantic  analyzer  cannot  perform  one  of 
Its  most  important  tasks,  type  and  overload  resolution.  Since  the 
value  must  be  known  to  the  Front  End.  it  Is  recorded  as  the  value  of 
an  attribute  to  avoid  the  need  for  recomputation  by  the  Back  End. 


1.3.4.  Examples 

A  few  examples  illustrate  these  principles; 

•  The  structure  of  a  type  (whether  it  is  an  integer,  an  array,  a  record, 

and  so  on)  can  be  deduced  by  searching  backward  through  the  chain 
of  derived  types  and  subtypes.  This  chain  could  be  of  arbitrary 
length,  and  so  the  search  is  not  tolerable.  Thus,  a  subtype 

specification  (a  Diana  constrained  node)  has  an  attribute 

sm_jype_struct  to  record  this  information. 

•  The  parent  type  of  a  derived  type  is  identical  to  the  base  type  of  the 
subtype  Indication  given  In  the  derived  type  definition,  and  this  infor¬ 
mation  Is  already  recorded  In  the  sm_pase_type  attribute  of  the 
constrained  node  which  is  a  child  of  the  derived  node.  Thus  no 
parent  type  indication  Is  needed  in  the  derived  node. 

•  Some  Diana  users  have  suggested  adding  an  attribute  to  each 

OEF.OCCURRENCE  node  to  denote  the  node  for  the  enclosing 

namescope.  Although  locating  the  enclosing  namescope  (if  the  at- 
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tribute  is  not  available)  can  Involve  visits  to  more  than  three  or  four 
nodes,  a  Diana  reader  can  readily  compute  this  attribute  and  decorate 
the  tree  with  It  as  the  Diana  Is  read  in.  Since  this  attribute  contains 
Information  that  may  not  be  useful  to  every  implementation  and  fur¬ 
thermore  Is  easy  to  compute  in  the  above  sense,  it  is  not  provided  in 
Diana. 


1 . 4.  Notation 

As  we  have  stated  several  times.  Diana  is  an  abstract  data  type  that  can  be 
modeled  as  an  attributed  tree.  In  this  document  we  are  concerned  with  defining 
this  abstract  type— both  Its  domain  and  its  operations.  The  domain  of  the  Diana 
type  is  a  subset  of  the  (mathematical)  domain  known  as  attributed  trees.  In 
order  to  specify  this  subset  precisely,  we  introduce  some  special  notation,  a 
subset  of  a  notation  called  IDL  (91.  A  knowledge  of  IDL  is  not  necessary  to  read 
or  understand  this  document— all  necessary  information  about  the  notation  is 
defined  in  this  section.  (A  tew  additional  features  are  defined  in  Appendix  II  as 
they  are  used  only  there.) 

To  assist  the  reader  in  understanding  this  material,  certain  typographic  con¬ 
ventions  are  followed  consistently  throughout  this  document,  as  illustrated  in 
Figure  1-1. 


DECL  OP  DEF_OCCURRENCE 
constant  var  const_td 
/x_j3rcpo3  sm_addreas  aa_exp 

Structure  Boot  Type 

begin  case  pragma 

INTEGER  'SIZE  BOOLEAN 
Tax_rate  Walkl  Tree 


IDL  class  names 
IDL  node  names 
IDL  attributes 

reserved  word  in  IDL 

Ada  reserved  words 
Identifier  defined  by  Ada 
Identifier  in  an  Ada  program 


Figure  1-1 :  Typographic  Conventions  used  in  this  Document 


The  set  of  abstract  trees  used  to  model  the  Diana  type  can  be  viewed  as  a 
language,  one  whose  terminal  sentences  happen  to  be  attributed  trees  rather 
than  strings  of  characters.  The  definition  of  this  language  can.  therefore,  be 
given  in  a  form  similar  to  BNF.  In  particular,  we  use  two  definitional  forms  that 
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resemble  the  production  rules  of  6NF.  The  first  of  these  defines  non-terminals 
of  the  description.  Consider,  for  example,  the  following  definition: 

EXP  :  s-  leaf  I  tree  j 

As  is  customary,  this  definition  may  be  read,  'The  notion  of  an  EXP  is  defined 
to  be  either  a  leaf  or  a  tree. '  Symbols  such  as  EXP  are  called  class  names: 

names  of  nodes  In  the  'tree  language'  are  called  node  names.  In  this  case, 

both  alternative  definitions  for  EXP  are  node  names.  Class  names,  like  non¬ 
terminals  in  BNF,  never  appear  in  the  sentences  of  the  language:  their  only  use 
is  In  defining  that  language.  Node  names,  on  the  other  hand,  appear  in  the 
sentences  (that  is  the  trees  of  our  tree  language).  Notice,  by  the  way.  that 
each  definitional  rule  Is  terminated  by  a  semicolon. 

The  use  of  this  form  of  definition  is  more  restricted  than  In  usual  BNF.  The 

right  hand  side  of  the  production  may  be  only  an  alternation  of  one  or  more 

class  or  node  names  and  may  not  be  a  concatenation  of  two  items  (as  it  may 

be  in  BNF).  In  addition,  class  names  may  not  depend  upon  themselves  (in  a 

circular  fashion)  Involving  only  the  : :  ='  form  of  definition  rules.  Thus  a 

directed  graph  constructed  with  an  edge  from  each  class  name  on  the  left  to 

each  alternate  on  the  right  will  be  acyclic:  that  is.  it  will  be  a  DAG. 

As  Is  usual  with  BNF,  there  may  be  more  than  one  such  production  with  the 
same  left  hand  side  (class  name):  definitions  after  the  first  merely  introduce 
additional  alternatives.  Thus,  the  effect  of  the  two  definitions 

EXP  :  !•  leaf  ; 

*  •  • 

EXP  : :■  tree  ; 

Is  no  different  from  that  of  the  single  definition  given  earlier. 

The  definition  of  the  node  names  must  specify  the  attributes  that  are  present 
In  that  node,  as  well  as  the  names  and  types  of  these  attributes.  We  again  use 
a  BNF-lIke  form  for  such  definitions.  To  prevent  confusion,  this  form  is  slightly 
different  from  the  definition  of  class  names:  for  example 

tree  ■»  opt  operator,  left i  exp,  right  t  exp  > 

Here  we  define  the  node  tree  and  associate  with  it  three  attributes  with  their 
names  (op.  left,  and  right )  and  their  respective  types  (OPERATOR.  EXP,  and 
EXP).  Unlike  BNF  (or  record  declarations),  the  order  of  attribute  specifications 
does  not  matter. 

The  right  hand  side  of  a  production  defining  a  node  name  is  also  restricted: 
it  may  be  only  a  sequence  of  zero  or  more  attribute  specifications  separated  by 
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commas  and  terminated  by  a  semicolon.  Multiple  definitions  of  a  node  name 
are  permitted:  definitions  after  the  first  add  additional  attribute  specifications— 
they  are  not  alternatives  but.  rather,  define  additional  attributes  of  the  node. 
Thus,  for  example. 


and 


tree  ->  ops  OPERATOR  j 
«  •  « 

tree  -»  left:  exp,  right:  exp  ; 


tree  •>  ops  OPERATOR  > 
•  •  • 

tree  »  right:  EXP  j 
tree  «>  left s  EXP  j 


are  both  identical  In  effect  to  the  single  definition  given  earlier.  Note  also  that 
the  order  of  both  the  ’ : :  and  '=>'  definition  rules  is  irrelevant:  all  orders  are 
equivalent  (as  in  BNF) .  In  particular,  we  reversed  the  order  of  definition  of  the 
left  and  right  attributes  in  the  last  example  above:  doing  so  has  no  effect. 


On  occasion  it  is  useful  to  specify  a  node  which  has  no  attributes,  as  tor 
example 

foo  ->  ) 

Nodes  so  defined  are  used  much  like  enumeration  literals  in  Aoa.  See.  tor 
example,  the  nodes  plus,  minus,  times,  and  divide  in  Figure  1-2  on  page  26. 


There  are  two  kinds  of  permissible  attribute  types:  basic  types  defined  by  the 
IDL  notation,  and  private  types.  The  basic  types  are: 


Boolean 


These  are  the  conventional  boolean  type:  the  only  permis¬ 
sible  values  of  such  an  attribute  are  true  and  false. 


integer 

Rational 


String 
Seq  Of  T 


This  is  the  'universal  Integer'  type. 

This  is  the  'universal  rational  number'  type,  which  includes 
all  values  typically  found  in  computer  integer,  floating  point 
and  fixed  point  types. 

These  are  ASCII  strings. 

This  is  an  ordered  sequence  of  ob|ects  of  type  T. 


<name>  The  <name>  must  be  that  of  either  a  node  or  class  name 

defined  elsewhere.  Use  of  <name>  as  an  attribute  type 
denotes  a  reference  to  either  an  instance  of  that  node  (In 
the  case  of  a  node  name)  or  any  of  the  nodes  that  can  be 
derived  from  it  (in  the  case  of  a  class  name) .  Note  that 
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a  reference  here  does  not  necessarily  mean  a  pointer  in 
the  concrete  Implementation;  direct  Inline  inclusion  of  the 
node  is  permitted,  as  well  as  a  number  of  other  implemen¬ 
tations.  (See  Chapter  6  for  a  discussion  of  some  of  the 
implementation  alternatives.  > 

A  private  type  names  an  implementation-specific  data  structure  that  is  in¬ 
appropriate  to  specify  at  the  abstract  structure  level.  For  example.  In  Diana  we 

want  to  associate  a  aourca_poaltlon  attribute  with  each  node  of  the  abstract  tree. 
This  attribute  is  useful  for  reconstructing  the  source  program,  for  reporting 
errors,  for  source-level  debuggers,  and  so  on.  It  is  not  a  type,  however,  that 
should  be  defined  as  part  of  this  standard  since  each  computer  system  has 
Idiosyncratic  notions  of  how  a  position  In  the  source  program  is  encoded.  For 
that  matter,  the  concept  of  source  position  may  not  be  meaningful  If  the  Diana 
arises  from  a  syntax  editor.  For  these  reasons,  attributes  such  as  source 
position  are  merely  defined  to  be  private  types. 

A  private  type  Is  introduced  by  a  type  declaration.  The  declaration  of  the 
private  type  'MyType'  would  be 
Type  MyType; 

Once  such  a  declaration  has  been  given,  the  type  name  may  be  used  In  an 

attribute  specification.  For  example, 
tree  ->  next  MyType  » 

Before  proceeding,  we  need  to  make  a  few  remarks  about  the  lexical  struc¬ 
ture  of  the  IDL  notation.  First,  as  In  Ada  a  comment  Is  Introduced  by  a  double 
hyphen  * — '  and  is  terminated  by  the  end  of  the  line  on  which  it  appears. 
Second,  the  notation  is  case  sensitive;  that  is.  identifiers  that  are  spelled 

Identically  except  for  the  case  of  the  letters  In  them  are  considered  to  be 
different  identifiers10.  Finally,  names  (Identifiers),  as  In  ADA.  consist  of  a  letter 
followed  by  an  optional  sequence  of  letters,  digits,  and  Isolated  underscore 
characters  ( . 

The  final  point  to  be  made  about  the  notation  Is  that  the  definitional  rules 
Illustrated  above  are  enclosed  in  a  syntactic  structure  that  provides  a  name  for 
the  entity  being  defined  together  with  the  type  of  the  goal  symbol  of  the 
grammar.  For  example,  the  IDL  text 


^Caee  sensitivity  M  viewed  by  some  u  a  questionable  notational  property;  tn  this  Matanoe  K  was 
adapted  to  aupport  a  direct  correspondence  with  the  AFD  (which  la  oaae  sensitive). 
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Stxucture  SoooWbo  Root  EXP  Is 

—  >om  sequence  of  dofinltional  rulss 
End 

assorts  that  tho  collection  of  production  rules  defines  an  abstract  type  (or 
Structure  in  IDL  terminology)  named  'SomeName'  and  that  the  root  of  this 
structure  is  an  EXP.  where  EXP  is  defined  by  the  set  of  definitional  rules.  In 
the  case  of  Diana  we  are  defining  a  single  abstract  type,  so  there  is  a  single 
occurrence  of  this  syntax  that  surrounds  the  entire  Diana  definition;  other  uses  of 
IDL  may  require  several  Structure  definitions.  Expanding  on  the  analogy  that 
IDL  is  like  BNP.  the  Root  defined  here  is  the  'goal  symbol'  of  the  grammar:  all 
valid  instances  of  the  type  defined  by  the  IDL  specification  are  derived  by 
expanding  this  symbol. 

1.4.1.  Example  of  the  IDL  Notation 

The  following  example  illustrates  the  use  of  the  notation.  It  is  Intentionally 
chosen  nor  to  be  Diana  to  avoid  confusion.  Suppose,  then,  that  we  wish  to 
describe  an  abstract  type  for  representing  simple  arithmetic  expressions.  We 
might  use  a  definition  such  as  the  one  shown  in  Figure  1-2  on  page  26. 
Although  this  example  Is  qulto  simple.  It  does  Illustrate  the  use  of  all  of  the 
features  of  the  (OL  notation  that  are  used  to  define  Diana.  Two  class  names  are 
defined;  EXP  and  OPERATOR.  Since  they  name  classes  and  not  nodes  (as 
indicated  by  our  typographic  conventions) .  neither  appears  in  the  trees  In  the 
abstract  type  (structure)  * ExpressionTree' .  There  are  six  node  names  defined: 
tree.  leaf.  plus,  minus,  times,  and  divide.  Each  of  these  may  appear  as  a 
node  in  the  trees.  Of  the  nodes,  only  trees  and  leafs  have  attributes,  and  the 
names  and  types  of  these  attributes  are  given.  An  implementation-defined 
private  type.  Source_Posltlon.  Is  defined;  both  trees  and  leafs  have  attributes  of 
this  type.  Finally,  the  fact  that  the  root  of  the  tree  must  be  an  EXP.  that  is. 
either  a  tree  or  a  leaf  node.  Is  specified.  Figure  1-3  on  page  27  illustrates 
several  trees  that  are  defined  members  of  ExpressionTree;  for  expository  reasons 
the  names  of  the  attributes  and  the  source  position  attribute  have  been  deleted 
from  these  pictures.  Similar  conventions  are  used  In  the  figures  In  Chapter  3. 

1.4.2.  Specification  of  Representations 

IDL  can  be  used  to  define  a  refinement  of  a  structure  as  well  as  an  abstract 
data  structure.  A  refinement  Is  treated  the  same  as  any  other  abstract  structure 
specified  In  IDL.  A  refinement  of  a  structure  is  used  to  provide  more  detail 
about  the  abstract  structure.  In  this  document  we  define  a  refinement  of  Diana 
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Structure  Express ionTrss  Root  EXP  I* 

—  First  we  define  a  privat*  type. 

Type  Souxc*_?osition; 

—  Next  ws  define  the  notion  of  an  expression,  EXP. 
EXP  : !-  leaf  I  tree  i 


—  Next  w*  define  the  nodes  and  their  attributes. 

tree  ->  opt  OPERATOR,  left :  EXP,  rlghti  EXP  ; 

tree  ->  arc  t  Sourcs_position  > 

leaf  ->  nam St  String  ; 

leaf  ■»  arc:  Source_Position  > 


—  Finally  we  define  the  notion  of  an  OPERATOR  as  the 

—  union  of  a  collection  of  nodes;  the  mill  •»  productions 

—  are  needed  to  define  the  node  types  since 

—  node  type  name  are  never  Implicitly  defined. 

OPERATOR  i  :■  plus  I  minus  I  times  I  divide  ; 
plus  ■>  ;  minus  ->  >  times  ■>  i  divide  ■*>  ; 


End 


Figure  1-2:  Example  of  IDL  Notation 


that  provides  representation  information  for  the  private  types  defined  In  Diana. 

IDL  can  be  used  to  define  the  package  that  contains  the  internal  represen¬ 
tation  of  a  privat*  type,  and  can  specify  the  external  representation  of  a  private 
type.  We  add  this  information  to  the  Diana  abstract  type  in  the  structure 
Dlana.Concrete  In  Chapter  2  on  page  77. 

The  Internal  representation  of  a  private  type  Is  described  by  a  definition  of 
the  form 

For  NyTyps  Os*  MyPackags; 


w  V  ?'  ■'*  > 
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Figure 


i««r 

"xyz* 


tree 


leif  plus  leif 
•atoc"  'def* 


tree 


leaf  times  tree 


tree  plus  leaf 


leaf  minus  leaf 
"x"  "z" 


1-3:  Some  Trees  in  ExpreaslonTree 
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This  definition  Introduces  the  name  ot  the  package  ('MyPackage'  in  this  case) 
where  the  definition  of  a  private  type  ('MyType'  in  this  case)  is  found. 

The  way  a  private  type  is  to  be  represented  externally  can  be  described  in  a 
definition  of  the  form 

for  MyType  be*  External  ExtarnTyp#; 

This  definition  asserts  that  the  private  type  MyType  Is  represented  by  the  type 
'ExternType'  externally.  The  external  type  may  be  one  of  the  basic  IDL  types  or 
a  node  type. 

The  refinement  of  a  structure  is  specified  with  the  following  syntax 

Structure  AnotherTree  Refines  ExpressionTree  Is 

—  Additional  IDL  statements  to  further  define  the 

—  structure  ExpressionTree,  such  as  a  specification  of  the 

—  internal  and  external  representations  for  private 

—  types  in  the  abstract  structure  ExpressionTree. 

—  New  nodes  say  be  defined. 

End 

1.4.3.  Example  of  a  Structure  Refinement 

The  following  example  illustrates  the  use  of  the  structure  refinement  notation. 
To  continue  with  our  example,  suppose  we  wished  to  refine  the  abstract  type 
ExpressionTree  by  adding  an  internal  and  external  representation  to  be  used  for 
the  private  type  Source.Position.  We  might  refine  the  structure: 


structure  AnotherTree  Bananas  ExpressionTree  Is 

—  first  the  internal  representation  of  Source_Position 
For  Source_Po«it ion  use  Source_Package> 

—  next  the  external  representation  of  SourceJPosition 

—  is  given  by  a  new  node  type,  source_extemal_rep 

For  SourceJPosition  Use  External  source_*xternal_rep; 

—  finally,  we  define  the  node  type  source_extemalwgsp 

source_extexnal_rep  ->  file  t  String, 

line  t  Integer, 
char  i  integer; 


End 


Introduction 
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This  example  completes  the  discussion  ot  I0L.  Notice  that  in  the  second 
example  the  internal  representation  and  the  external  representation  lor  the  private 
type  are  both  given.  The  internal  representation  is  described  In  a  separate 
package  called  Source.Package.  The  external  representation  is  dellned  as  a 
node.  source_externai_rep .  that  has  three  attributes,  a  file  name,  represented 
externally  as  a  string,  and  a  line  number  and  character  position,  both  of  which 
are  represented  externally  by  the  basic  type  'Integer'.  At  the  end  ot  Chapter 
2  we  present  a  refinement  Diana.Concrete  of  Diana.  In  Chapter  5  we  define  the 
canonical  external  representation  of  Diana. 


1.4.4.  Diana  Notational  Conventions 

The  definition  of  Diana  given  In  the  next  chapter  observes  some  notational 
conventions  that  are  intended  to  improve  the  readability  of  the  presentation. 
These  include: 

•  Wherever  reasonable,  both  nodes  and  classes  are  named  as  in  the 
AFD. 

•  Typographic  conventions  are  adhered  to  for  class  names,  node 
names,  and  attributes  to  assist  the  reader.  These  conventions, 
which  are  are  listed  In  Figure  1-1  on  page  21.  are  that  class  names 
appear  In  all  upper-case  letters,  nodes  names  In  all  lower  case,  and 
attribute  names  italicized. 

•  A  class  name  or  node  name  ending  in  ‘.S'  or  '.s'  respectively  is 

always  a  sequence  of  what  comes  before  the  Thus  the  reader 

can  be  sure  on  seeing  a  class  name  such  as  FOO_S  that  the 
definitions 

POO_3  ■>  foo_s  j 

Coo_8  ->  as_listi  Seq  of  PCX)  > 

appear  somewhere. 

•  A  class  name  ending  in  '.VOID'  always  has  a  defini¬ 
tion  such  as 

F00_V0ID  ->  POO  I  void  } 

•  •  * 

void  ■»  r 

The  node  voM  has  no  attributes. 

•  There  are  four  kinds  of  attributes  defined  In  Diana:  structural. 
lexical,  semantic,  and  code.  The  names  of  these  attributes  are 
lexically  distinguished  in  the  definition  as  follows: 

as.  structural  attribute.  The  structural  attributes  define  the 
abstract  syntax  tree  of  an  ADA  program.  Their  names  are 
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thoa*  us«d  in  tho  AFD.  prefixed  with  %aa__*. 

Zx_  lexical  attributes.  These  provide  Information  about  the 

source  form  of  the  program,  such  as  the  spelling  of 
Identifiers  or  position  In  the  source  file. 

sm_  semantic  attributes.  These  encode  the  results  of  semantic 
analysis— type  and  overload  resolution,  for  example. 

cd_  code  attributes— there  is  only  one.  This  provides  infor¬ 
mation  from  representation  specifications  that  must  be  ob¬ 
served  by  the  Back  End. 

•  Although  IOL  is  insensitive  to  the  order  of  attribute  definitions 
with  *=>'  rules,  we  have  preserved  the  order  used  in  the  AFD. 
Additionally,  for  emphasis  we  have  grouped  structural,  lexical, 
semantic,  and  code  attributes,  always  in  that  order. 

•  The  Diana  definition  Is  organized  In  the  same  manner  as  the 
Aoa  LRM.  To  establish  the  correspondence,  each  set  of  Diana  rules 
begins  with  a  comment  that  gives  the  corresponding  section  number 
of  the  Aoa  LRM  and  the  concrete  syntax  defined  there. 


Definition  of  the  Diana  Domain 
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CHAPTER  2 

DEFINITION  OF  THE  OIANA  DOMAIN 


This  chapter  is  devoted  to  the  definition  of  the  domain  of  the  Diana  abstract 
type  —  that  Is.  to  the  definition  of  the  set  of  attributed  trees  that  model  the 
values  of  the  Oiana  type.  The  definition  is  given  in  the  notation  discussed  in 
section  1 . 4. 

A  simple  refinement  of  the  Diana  abstract  structure  follows  the  definition  of  the 
Diana  domain.  This  refinement  defines  the  external  representation  of  the  private 
types  used. 

Before  beginning  the  definition,  which  constitutes  the  bulk  of  this  chapter,  we 
make  two  observations  about  things  that  are  not  defined  here. 

•  First,  there  are  six  private  types  used  in  the  definition.  Each  of 

these  corresponds  to  one  of  the  kinds  of  information  which  may  be 
Installation  or  target  machine  specific.  They  include  types  for  the 
source  position  of  a  node,  the  representation  of  identifiers,  the 
representation  of  various  values  on  the  target  system,  and  the 
representation  of  comments  from  the  source  program.  The  Diana 
user  must  supply  an  implementation  for  each  of  these  types. 

•  Second,  as  is  explained  in  the  Ada  reference  manual,  a  program  is 

assumed  to  be  compiled  in  a  'standard  environment'.  An  Ada 

program  may  explicitly  or  implicitly  reference  entities  defined  in  this 
environment,  and  the  Diana  representation  of  the  program  must  reflect 
this.  The  entities  that  may  be  referenced  include  the  predefined 
attributes  and  types.  The  Diana  definition  of  these  entities  is  not 
given  here  but  Is  assumed  to  be  available.  See  Appendix  I  for  more 
details. 


With  these  exceptions,  the  following  completely  defines  the  Oiana  domain. 


I 
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Structure  Duma 
Root  COMPILATION  la 
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—  version  of  17  February  1983 


Type  source _po*ition; 


Type  coffliMAtt; 


Typu  *ymboi_rep; 


Type  value; 


Typu  operator; 


Type  number_rep; 


—  2.  lexical 


—  detinea  source  position  in  original 

—  source  program;  used  for  error  messages. 


—  representation  ot  comment*; 

—  source  reconstruction. 

—  representation  ot  identifiers, 

—  strings,  and  characters 


—  implementation  defined 

—  gives  value  of  a  static  expression; 

—  can  indicate  that  no  value  is  computed. 

—  enumeration  type  for  an  operators 

—  used  in  implementation 

—  representation  of  numeric  literal* 


Syntax  2.0 

has  no  equivalent  in  concrete  syntax 


void  » 


—  has  no  attributes 


—  2.3  Identifiers,  2.4  Numeric  Literals,  2.6  String  Literals 


Syntax  2.3 

not  of  interest  for  Diane 


K> 

OP 

OeStQMATOR 


DCF  JO  I  USCDJO; 
DCF_0P  I  U8EDJJP; 
10  I  OP; 


COOCCURRENCE  ::s  DCF  JO  I  06F_0P  I  DEF_CHAR; 
—  see  4.4  for  numeric  literal 


*  •  •  •• 
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_ 2.8  pta^iu 

—  These  production*  do  not  correspond  to  productions  in  the 

—  concrete  syntax . 

—  Syntax  2. 8. A 

—  pfigmi  ; ;  s 

—  pragma  identifier  [  (argument_a*sociation  {,  argument_association})]; 


PRAGMA 


pragma; 


pragma  => 
pragma  => 


aa_id  :  ID,  —  a  'used_name_id' 

ss_faram_sssoc_s  :  PARAM_ASSOC_S; 
lx_arcpca  :  so«rce_position, 

/x_commenfa  :  comments; 


PARAM_ASSOC_S  :  :=  param_assoc_s; 

param_assoc_s  =>  aa_Uat 

param_assoc_s  ->  lx_arcpoa 

lx_commf>ta 


Seq  Of  PARAM_ASSOC; 

source_position, 

comments; 


—  Syntax  2.8.B 

—  argument_association  : ;  = 

—  [  argument.,  identifier  *>J  name 

—  I  [srgumenf~identlfier  =>]  expression 


—  see  6.4  for  associations 


—  3.  Declarations  and  Types 
—3.1  Declarations 


—  Syntax  3.1 

—  declaration  ; ;  = 

—  object_dedaration 

—  I  type_dedaration 

—  I  subprogram_dectaration 

—  I  tasfc_declaratk>n 

—  I  exceptton_dedaration 

—  I  renaming  declaration 


I  number_dedaraHon 
I  *ubtype_deciaration 
1  package_dedaraHon 
I  genOr*c_declaration 
1  generic_instantiation 
I  deferred..  constant_dectaratfon 


DECt 


constant  I  var 


number 

typ« 

subtype 

subprogram  _ded 
pecXege_deci 
tasfc_ded 
generic 


—  obiect_dedaratton  (3. 2. A) 

—  number_dedaratton  (3.2.B) 

—  type_dedaration  (3.3.1) 

—  subtype_dedaration  (3.3.2) 

—  subprog7am_deciaratton  (6.1) 

—  package_declaratton  (7.1) 

—  task_dedaratton  (9.1) 

—  generic_dedaration  (12.1) 
except ion_deciaration  (ii.i) 


exception  _ 

—  See  12.3  for  generic_instantlation, 

—  See  8.5  for  renaming_dedaration, 

I  deferred  constant;  —  deferred_constant_dedaration  (7.4) 


OECt 


pragma; 


—  pragma  allowed  as  declaration 


Ada  Section  2.3 
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?' 


—  3.2  Object*  and 


Syntax  3. 2. A 

ob>ect_decl*retlon  .uhtvoa  indication  f  :=  expression); 

:  ,  gssyg ;  [SSSS1  t- 


OBJECT  _OEF 

EXP  VOID  = 

rrpC_sf*ec 

constant  => 


constant  -> 


var  s> 


var  => 


EXP_V01D; 

EXP  I  void; 
CONSTRAINED; 

aajd-s 

aa_type_sp*c 

aa_obpct~.d*t 

lx_arcpos 

lx_commer><3 

as_fd_a 

aajype_ap«c 

aa_oejact_dar 

/x_srcpos 

lx_con>wnta 


10  s,  —  sequence  ot  'cons^vd' 
TYPE_SPEC, 

OBJECT_DEF; 
source __position, 
comments; 

10  S,  —a  sequence  ot  Var_id' 
TYPE  SPEC, 

08JECT_DEF; 

source__position, 

comments; 


OEFJO  = 
var_id  »> 

var_id  -> 


»ar_id; 

/x_srcpos 

lx_comw*fita 

/x_symrap 

sm_ot>i_type 

amjaddnaa 

a/n_ot>i_d«f 


source_position , 

comments, 

symbol_rep; 

ttpe  spec. 

expjvoio, 

OBJECT_DEF; 


OEF  10  ::=  const  Jd; 


const_id  => 
const_id  -> 


Ix^srcpoa 

/x_comments 

lx_aymr»p 

amjaddraaa 

amjobiJypa 

amJirM 


source_position, 

comments, 

symbol_rep; 

EXP  VOIO, 

rfPE_SPEC, 

OBJECT_DEF, 

OEF  OCCURRENCE; 


—  used  for  deferred 
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—  Syntax  3.2.8 

—  number  dtdiritton  : :  > 

—  identitier.ltst  :  constant  :*  «n/voraaf_«fattc_*xpreaaion; 


number  »> 

as_Ad_s 

as_*xp 

number  -> 

fx_srcpos 

/x_commenfa 

OEF.IO  = 

number.id; 

number.id  => 

fx.srcpos 

tx_commmnts 

/x.symrep 

number. id  -> 

am_.obL.lYP* 

am_jnit_0xp 

Syntax  3.2.C 

identifier.llst  ; 

:=  identifier  {.  identifier) 

ID.S  ::= 

id.*; 

id.s  => 

as_/isf 

id.s  => 

lx_arcpoa 

fx.commenfs 

—  3.3  Types  and  Subtype* 
~  3.3.1  type  Declarations 


—  Syntax  3.3.1. A 

—  type.dedaration  ::=  full.type.dedaration 

—  I  incomplete.type.declaration  I  private 


ID  S,  —  always  a  sequence  of  *number_id* 
EXP; 

aource_position, 

comments; 


:  source .position, 

:  comments, 

:  symbol  rep; 

:  TYPE  SPEC,  —  always  refers  to  a  universal  type 

:  EXP;“ 


:  Seq  Of  ID; 

;  source .position, 
:  comments; 


type.dedaration 


—  full.type.dedaration  ::  = 

—  type  identifier  [discriminant _part]  is  type.definitlon; 


—  see  7.4  for  pnvate.type.dedaration 

—  see  3.8.1  for  incompiete.type.dedaratton 

type  =>  as.id 


as_.dscrmf_var_a 

•a_typ*_ap*c 

type  =>  1x_wcpoa 

/x.commenfa 


OEF.IO  ::  = 
type.id  =» 

type.id  => 


typ*_W; 

lx_srcp08 

/x.commenfa 

/x.symrep 

sm_fyp*_spac 

smjttrrt 


ID,  —  a  type_kT, 

—  1_private_typ*_id"  or 

—  ■prtvata.type.kJ’ 

DSCPMT.VAR  S.  —  discriminant  list,  see  3.7.1 

TYPE _S PEC;  “ 

sourca_poartion, 

comments; 


sourea_pos(tion, 

comments. 


—  used  for  multi  pin  def 


Ada  Saction  3.  2.  A 


k 
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—  Syntax  3.3. 1.8 

—  type_definition  :  :  = 

—  enumerabon_type_definttion 

—  I  real_type_deftnitton 

—  I  record_type_definit>on 

—  I  derived_type_det*nition 


I  lnteger_type_detinitk>n 
I  erray_type_definltlon 
I  access_type_deftntbon 


TYPE_SPEC  enum_literal_s 

I  integer 
I  fixed  I  float 
I  errey 
I  record 
I  ecceee 
I  derived; 


—  enumeratlon_type_definition  (3.5.1) 

—  integer_type_definition  (3.5.4) 

—  real_type_definitk>n  (3.5.6) 

—  errey _type_definttion  (3.6) 

—  reeord_type_definit(on  (3.7) 

—  acces*_type_det1nition  (3.8) 

—  derrve<T_type_detimtion  (3.4) 


—  3.3.?.  Subtype  Declarations 


—  Syntex  3. 3. 2. A 

—  cubtype_decleretion  ; ;  =  subtype  identifier  is  subtype_lndfeation; 


subtype  => 
subtype  => 

OEF_ID 
subtype_id  => 

subtype_Jd  => 

Syntax  3. 3. 2. 8 


as_/d 

a«_eon  strained 

lx_arcpoa 

lx_commanta 


subtype_id; 

lx._arcpoa 

lx_comm»nta 

fx_symrep 

sm_fype_spec 


©. 

CONSTRAINED; 

source_position 

comments; 


source_positionl 

comments, 

symbol_rep; 

CONSTRAINED; 


subtype_indicetion  ;  :=  type_merk  [constraint] 
type_mark  ;  :=  fype_name  I  aubfype_name 


CONSTRAINED 
CONSTRAINT  : 

constrained  => 

constrained  => 

constrained  => 

constrained  => 


constrained; 

void; 

aa_/iama 

as_co natrunt 

lx_arcpoa 

Ix^commaoia 

am_typ*_atruci 

am_baaa_typa 

am_conatraint 

cd_/mpf_stie 


NAME, 

CONSTRAINT; 
source _position 
comments; 
•nrpe  spec, 

TYPE~SPEC, 

CONSTRAINT; 

Integer; 
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—  Syntax  3.3.2.C 


—  constraint  :  :* 

—  range.eonstraint  I  Hosting  point  constraint  I  itxed_po*nt_constra»nt 

—  I  lnd«x3on«traint  j  dlsc»lminant_constralnt 


CONSTRAINT 


RANGE  —  rang*  conttraint  (3.5) 

|  Moat  —  rtoatin5_j>oint_conttraint  (3.5.7) 

j  Hxad  —  ftxod_point_constraint  (3.5.9) 

I  dacrt  rang*  $  —  index  conttraint  (3.6.C) 

I  dacrrnt  aggregate;  —  dlscrlminant_constraint  (3.7.2) 


—  3.4  Oexieed  Type  Definitions 


—  Syntax  3.4 

—  derived_type_definition  :  :=  new  aubtypejndication 


derived  => 
derived  *> 

derived  »> 


derived  => 


aa_co nstra/ned 
ix_arcpoa 

am_«ze 

sm_ac(ua/_de#a 
am_pmMnq 
am_comroll*d 
sm_storag*_ait» 
cd _impt_siz» 


CONSTRAINED; 

*ourca_position, 

comments; 

EXPJ/OIO. 

Rational, 

Boolean, 

Boolean, 

EXP_VOtD; 

Integer; 


—  3.5  Scalar  Types 

—  Syntax  3.5 

—  range_constraint  : :  =  range  range 

—  range  :  ;=  ran ge_attri bote 

—  |  slmple_expressK>n  ..  slmple_expresswn 


RANGE 


range  I  attribute  I  attribote_caM; 


range  » 
range  *> 
range  *> 


«s_e*p7 

aa_exp2 

lx_srcpoa 

)x_commen(a 

am_baae_(ype 


EXP, 

EXP; 

source _position, 

comments; 

TTPE_SPEC; 


—  3.5.1  Enumeration  Types 


—  Syntax  3.5.1. A 

—  enumeration  type_deftniHon 

—  ( enumeration JiteraJ_specrfication  (,  enumeration_llteral_specitlcatlon)) 


enum_llterai_s  *> 
enwm_Meral_s  => 

enum  Merai_s  *> 
enum”ntefS_#  *» 


aa_Nat 

lx_arcpoa 

fx.commenfs 

cd_/mp7_s»ze 


Seq  Of  ENUM_UTERAL; 

source_posrtion, 

comments; 

EXP_VCSD; 

Integer; 
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—  Syntax  3.8. 1.8 

—  enumerstion_literai_speciftcation  enumerattonjtteral 

—  enumerabon_ilteraJ  : :  *  identifier  I  cheracterjiterai 


ENUM  LITERAL 

:«  enum_id  1  del  _  char; 

OEF  ©  :  :  = 

enum_id; 

0EF_CHAR 

def_char; 

enum_id  -> 

lx_arcpca 

/x_commonfa 

lx_aymr*p 

enum_id  => 

am_o6i_fype 

am_poa 

am_r*p 

def_char  => 

lx_arcpoa 

lx_comm*nta 

fx_symrep 

def_cher  => 

*m_ot)/_fype 
am  _poa 
s/n_r*p 

—  3.5.4  Intege 

r  Types 

—  Syntax  3.8.4 

—  integer_type_definltion  : :  =  range_constraint 

integer  => 

as_rsngs 

integer  »> 

lx_arcpoa 
/x_ cemmenfs 

integer  => 

«m_atfze 

sm_fype_sfruef 

sm_Peso_fype 

integer  »> 

cd_/mpi_aize 

—  3.5.6  Mai  Types 


*ource_po«ltion , 
comments, 

*ymbol_rep; 

rrPE_SP€C,  —  refers  to  the  'enum_liter»l_i* 
Integer,  —  consecutive  position  (bese"o) 

Integer;  —  user  supplied  representation  value 

source_position, 

comments, 

symbol_rep; 

TYPE_SPEC,  —  refers  to  the  'enum_lltersl_*' 
Integer.  —  consecutive  position  (base  0) 
Integer;  —  user  supplied  representation  velue 


RANGE; 

source_position, 

comments; 

EXP  VOID, 

TYPE  SPEC, 

TVPElSPEC;  —  ■derived' 
Integer; 


Syntax  3.8.6 
real_type_definition  :  := 

ftoirttng_point_con*traint  I  fixed _point_con»trsint 


—  see  3.8.7,  3.8.3 
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-  3.5.7  Floating  Point  Types 


—  Syntax  3.5.7 

—  floating  point  constraint  :  :» 

—  ftoattng_aocuracy_<lef1nrtton  [rmnga_con*traint] 

—  float! ng_accu racy_defi n ition  digits  «faMe_slmple_express»on 


RANGE_VOtO  :  :  = 
float  *» 
float  => 
float  *> 

float  => 


RANGE  1  void; 
as.txp 

ae_range_voM 

lx_arcpos 

Ixjcommanta 

amjtyp9_atrvct 

am_fi*mjypa 

cdjmpt_ain 


EXP. 

RANGE_VOIO; 

soorce_posrtion 

comments; 

EXP_VOIO. 

TYPE  SPEC. 
TYPE_SPEC;  - 
Integer; 


—  3.5.9 


Point 


—  Syntax  3.5.9 

—  f»xed_point  constraint  :  := 

—  fixed  accuracy  definition  [range_constratnt] 


ftxed_accuracy_deftnitlon 

; :  =  delta  static  _ 

fixed  »> 

aa_axp 

as__rango_vo«f 

fixed  =* 

lx_srcpos 

lx_commsnts 

fixed  => 

am_atza 

sm_acfuaf_dotta 

sm_prt* 

sm_Paao_fype 

fixed  =» 

cd _impi_»M 

EXP. 

RANQE_VOID; 
»ource_po  sitter 
comments; 
EXP_VdD, 
Rational, 
Integer, 
TYPE_SPEC;  - 
Integer; 


'derived* 


'derived* 
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—  3.6  Array  Types 


—  Syntax  3.S.A 

—  arrsy_type_definition  :  :  = 

—  uncon*tr«ined_arT«y_detimtion  1  constrained_array_deftnltion 

—  unoonstrained_array_definition 

—  array ( index_subtype_detinitlon  {,  index_subtype_definition})  of 

—  -  componenf_subtype_indication  “ 

—  constrained_array_definition  :  :  = 

—  array  mdex_con*traint  of  componanf_subtype_indieation 


array  3» 


array  *> 
array  3> 


aa_dacrt_ranga_s 

aa_c  onatraimd 

lx_srcpoa 

lx_comwnta 

am.size 

am_p*dang 


DSCRT_RANQE_S ,  —  index  subtypes  or  constraint 
CONSTRAINED;-  —  component  subtype 
source_posrtton, 
comments; 

EX  P_ VOID, 

Boolean; 


OSCRT_RANOE_S  ;  ;=  dscrt_range_s; 


dsert_range_s  »>  aa_/ist 

daert_range_s  =>  lx_srcpos 

lx_comm*nla 


Seq  Of  DSCRT_RANGE; 

source_position, 

comments; 


—  Syntax  3.6.8 

—  index_subtype_definition  ; :  =  type_mark  ranee  <  > 


DSCRT_RANQE  :  :=  index; 


index  a» 
index  *> 


aa_na/ne 

lx_srcpoa 

lx_comm*nta 


:  NAME; 

:  source_position> 
:  comments; 


—  Syntax  3.6. C 

—  index_oonatraint  ;  :*  (discrete_range  (,  discrete_range) ) 

—  discrete_range  ; : 3  tfacrefe_subtype_tndtcation  I  range 


D8CRT_RANGE  constrained  I  RANGE; 


- 
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—  3.7  Record  Types 


—  Syntax  3. 7. A 

—  record_type_definition  = 

—  component_li*t 


REP_VOtO 

record  => 
record  => 

record  *> 


REP  I  void; 

•ajiat 

/x_*rcpoe 

lx_commanta 

am_aiz* 

am_diacrimmanta 

am_packtng 

em_/ocord_apec 


Seq  Of  COMP; 

source_po*ition> 

comments; 

EXP_VOtO, 

OSCRMT_VAR_S, 

Booiean, 

REP_VOIO; 


—  Syntax  3.7.B 

—  component_Uet  ::  = 

—  component-declaration  {cornponem_decier«tton} 

—  I  (component_decieration}  variant— part 

—  I  nufl; 


—  component_declaration  ;  :* 

—  identifier— list  ;  component— subtype— definition  [ :=  expression]; 

—  component— subtype-definition  ;  :=  subtype_ind)cstion 


COMP 

var 

—  component— declaration  (3.2)  where  ID  is  acomp_td‘ 

1  verient_pert 

—  variant_part  (3. 7. 3. A) 

|  null_comp; 

—  nuN  (see  below) 

COMP  = 

pragma; 

—  prag  mas  are  allowed  in  component  declarations 

m#*_ comp  *> 

lx_arcpoa 

:  aourca_po*rtk>n, 

fx_commenfs 

;  comments; 

D€F_IO 

oomp_td; 

COMP_REP_VOIO  = 

COMP_REP  1  void; 

comp_ id  *» 

lx_arvpoa 

;  source— position. 

lM_commanta 

;  comments. 

/x.tymrep 

;  symbol  rep; 

comp_id  *> 

am_obi_typa 

:  TYPE-SPEC, 

amjnd_axp 

;  EXP_VOIO, 

am_comp_spec 

;  COMP  REP  VOID; 
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—  Syntax  3.7. 1 

—  discriminant _part 

—  (diseriminant_spacitteation  {;  discrtminant_spaciftcation}) 

—  dtscrlreinant_apactftcatlon  :  := 

—  idantlfiar_tist  :  typa_m*rk  [ :=  axprassion] 


DSCRMT_VAR_S  ;  :  = 

dscrmt_var_s; 

dacrmt_var_s  => 
dscrmt_var_s  => 

aajiat 

lx_arcpoa 

lx_commanta 

:  Saq  Of  08CRMT_VAR; 

:  sourca_po*itton,~ 

:  comments; 

DSCRMT_VAR  :  :  = 

dscrmt_var; 

—  wftara  IC  is  always  a  'dacrmt_id' 

dscrmt_var  => 

dsermt_var  »> 

a«_«f_a 

as_nama 

aa_obtact_dat 

lx_arcpoa 

lx_commanta 

:  10  S,  —  a  saquanca  of  *var  id* 

;  NAME. 

:  OBJECT_DEF; 

:  sourca_position, 

;  commants; 

OEFJO  :  ;  = 

dscrmt_id; 

dsermtjd  => 

dacrmt_id  *> 

tx_arcpoa 

lx_commanta 

lx_aymrmp 

am_ot>l_typ* 

am _jnrt_axp 

amjirat 

am_comp_ap*c 

;  soorca_positton, 

:  commants, 

:  symbol  rap; 

:  TYPE  SPEC. 

:  EXPjVOID. 

;  DEF  OCCURRENCE. 

:  COM>  REP_VOIO; 

—  3.7.2  Dlecriattnaixt  Constraints 


—  Syntax  3.7.2 

—  diacrimmant_con*tramt  : :  = 

—  (di*criminant_asaooation  {,  discriminant_association}) 

—  discrlminant_a8aociaUon  :  := 

—  [ d/scr/minanf  _*impia_n4ma  (  I  discriminant_simpla_nania}  =>]  axprassion 


d*crmt_aggragato  a>  aajiat  :  Saq  Of  COM P_ ASSOC; 

dscrmt.aggragsta  =>  lx_arcpoa  ;  sourca_position, 

lx_comwnta  ;  comm  ant*; 

dscrmt_aggragsta  =>  am_normaliz»d_comp_a  :  EXP_S; 

—  aaa  4.3.B  for  discriminant  association 


>  #. 
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Syntax  3. 7. 3. A 

variant_part  :  :=  _ . 

oaae  0/aer/nwianf_simpie_name  ia 
variant 


{variant} 


variant  ::=  .  . 

when  choice  { I  choica}  3» 

componant_U*t 


variant __part  «> 

variant_part  *> 

aa_nama 

as_var<an<_s 

(x_srcpos 

/x_cammenfa 

VARIANT_S  ;;  = 

variant_s; 

variant_s  *> 
vartant_s  »> 

aaj/af 

lx_arcpoa 

/x_commenfs 

VARIANT  : ;« 

CHOICE  S 
INNER_RECORO 

variant; 

cho»ce_s; 

inner_recort; 

choice_a  => 
choice_s  *> 

aajfef 

fot_srepo« 

/x_commenta 

variant  *> 

variant  -> 

aa_chotce_s 

M_raconf 

lx_arcpoo 

lg_eomm»nt» 

innar_racord  => 
lnner_racort  *> 

aa_/« 
lx_src  poa 
/x_comn*anf« 

NAME, 

VARIANT_S; 

aourca_poaition, 

comments; 


Saq  Of  VARIANT; 
sou  rca_po»ition , 
commants; 


Saq  Of  CHOICE; 

sourca_positmn , 
commants; 

CHOICE_S, 
INNER_RECORO; 
sourca_posit(on , 
commants; 

Saq  Of  COMP; 

sourca_positton, 

commants; 


Syntax  3.7.3.B  _ 


CHOICE 
others  »> 


EXP  I  OSCRT_RANQE  I  others; 


f«_«rcpos 
/x  .comment  a 


source  _positiont 
comments; 
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—  Syntax  3.8 

—  aeceu.type.definition  :  :=  aooeu  subtypajndlcatton 


aooaaa  =>  aa_c onatrmmd 

aooaaa  =>  lx_arcpcs 

lx_comm*nta 

accau  *>  sm.siie 

am_stor*  pe.s/za 
am.c onfrotfed 


—  See  4.4.C  tor  iwN  accau  valua 


CONSTRAINED; 
source .position, 
comments; 

EXP  VOID, 
EXP.VOIO, 
Boolean; 


—  3.1.1  Xnoaeplete  Type  Declarations 

—  Syntax  3.8. 1 

—  incomplete,  type.declaration  type  Identifier  [discrtminant_part]; 


TYPE.SPEC  :;=  void; 

—  incomplete  types  are  described  in  the  rationale  Section  3. 5.1.1 


-  3.9  Declarative  Parts 


—  Syntax  3. 3. A 

—  d«clarattve_part  = 

—  {basic.declarati  ve.i  tom }  {later.declarative.item} 

—  bas*c_declarattve_item  :  :=  butc.declaration 

—  I  representation.clause  1  use.clause 


DECL  ::=  REP  I  use;  —representation  is  declarative  item 


—  Syntax  3.3.B 

—  later_dedarative_item  :  :=  body 

—  I  subprogram.dederatton  I  package.dedaration 

—  I  task.dedaratton  I  genertc.dedaratkon 

—  I  use.clause  I  genertc.instantlatton 

—  body  : proper.body  I  stub 

—  proper.body  ::=  subprogram.body  I  packege.body  I  tash.body 


ITEM.S  :  :=  item.s; 

ITEM  ;;s  DECL  I  subprogram.body  I  pacfcage.body  I  task.body; 

—  see  3.1,  6.1,  7.1,  9.1,  10.2  (stub  included  in  .body  definitions) 


item.s  »>  aa_/ist 

item's  x  >  /x.srcpoe 

A*,  comment  a 


Seq  Of  ITEM; 
source  .position, 
comments; 


V - 

i 
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—  ♦. 

—  4.1 


Hmm  and 


Expressions 


—  Syntax  4. t.A 

—  name  stmpie_na/ne 

—  I  ctiaracter_Hterai  I  operator_iymbol 

—  t  indexed_component  I  slice 

—  I  selected_component  I  attribute 

—  simple_name  :  :=  identifier 


NAME  ::  = 

USEDJD  ::  = 
used_object_id  => 

usad_obt«ct_id  => 

used_name_id  -> 

used_name_)d  =» 
used_bltn_id  *> 

used  Wtn  kt  => 


DESIGNATOR 
I  used_char 
I  indexed 
I  slice 
I  selected  I 
I  attribute  I 


—  identifier  and  operator  (2.3) 

—  character^ rteral  (see  below) 

—  indexed  component  (4.1.1) 

—  slice  (4.1.2) 

alt  —  selected_component  (4.1.3) 
attribute_call;  —  attribute  (4.1.4) 


used_ob)ect_id  |  used_name_td  |  used_Wtn_»d; 


lx_arcpoa 

lx_commania 

lx_aymrap 

sm_exp_fype 

sm_de/n 

am_value 


source_position, 

comments, 

symbol  rep; 

TYPE_SPEC, 

DEFOCCURRENCE, 

value; 


lx_srcpoa 

/x_commenfa 

lx_aymrap 

am_datn 


source_positlon, 

comments, 

symbol_rep; 

DEFOCCURRENCE; 


lx_arcpoa 

fx_commenfa 

lx_symrap 

am_oparator 


source_potiition, 

comments, 

symbol_rep; 

operator; 


—  see  3.8.5  of  rationale  for  a  discussion  of  built-in  subprograms 


USED_OP 


used_op  I  used_tXtn_op; 


used_op  -> 


used_op  => 


rx_srcpos 

lx_commanta 

Ixjsymrap 

am_datn 


source_poaitlon, 
comments, 
symbol  rep; 
DEF_OCCURRENCE; 


used_bltn_op  *»  lx_arcpoa 

fx_commenfa 

lx_3ymr*p 

used_bltn_op  *>  sm_operafor 


sou  rce_po«tion , 
comments, 
symbol_rep; 
operator; 


used_char  «> 


used_cfiar  *> 


fx_arcpoe 

fx_commenfs 

Ixjaymrap 

am_defn 

sm_exp_fype 

am_vakim 


sou  rce_  position, 

comments, 

symbol  rep; 

DEF_OCCURRENCE, 

rfPE_SP€C, 

value; 


—  Syntax  4.1.8 

—  prefix  name  I  functkm_call 


NAME 


funct)on_call;  —  see  6.4 


ADA  Section  3.9.B 


Page  46  /  Section  2 


Diana  Reference  Manual 


—  4.1.1  Indued  Coeponente 

—  Syntax  4.1.1 

—  indexed.component  :  :=  prefix  (expression  {,  expression}) 


EXP.S  : :  =  exp.s; 


exp_s  => 

as.f/sf 

Sep  Of  EXP; 

exp~s  => 

lx_srcpoa 

source .position 

lx_commarrta 

comments; 

indexed  => 

as_na/ne 

NAME. 

as_exp_« 

EXP_S; 

indexed  => 

lx_arcpoa 

source  .position 

/x.commenfs 

comments; 

indexed  => 

a»»_sxp_fype 

TYPE.SPEC; 

4.1.2  Slice* 

Syntax  4.1.2 

slice  prefix  (discrete. 

.range) 

slice  => 

ae_/iame 

:  NAME. 

as.dacrt.renge 

;  DSCRT.RANGE; 

slice  => 

lx_arcpoa 

:  source  .position. 

lx_commanta 

:  comments; 

slice  => 

sm.exp.fype 

am_conatraint 

:  TYPE  SPEC. 

:  CONSTRAINT; 

4.1.3  Selected 

Ccaponents 

Syntax  4.1.3 

—  select ed_component  :  :=  prefix. selector 

—  selector  : :  a  simple.neme 

—  I  cfteracter.literal  I  operstor_symbol  I  «N 


DESIGNATOR.CHAR : :  =  DESIGNATOR  |  used.cher;  —  character  literals  allowed  as  selector 


selected  => 
selected  » 
selected  => 


aa_name 

•a_d98tgnaior__chtf 

lx_arcpo* 

lx_eemmanta 

sm_exp_fype 


NAME. 

DESIGNATOR.CHAR; 

*ource_positk>n, 

comments; 

TYPE.SPEC; 


all  s> 
sH  *> 

all  «» 


ee_/*ame 

tx_arcpo* 

to.commenfs 

sm.exp.fype 


NAME;  —  used  for  name. all 

source_posittonl 

comments; 

■PfPE.SPEC; 
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—  4.1.4  Attributes 

—  Syntax  4.1.4 

—  attribute  :  :=  pretix'attribute_designator 


attribute_designator  : 

;=  simpie_name 

[  (un/versa/_sfaf/c_expression)  ] 

attribute  => 

as  _name 

:  NAME, 

aa_id 

:  ID;  —  always  a  'used_name_id', 

—  whose  attributes  point  to 

—  a  predefined  *attr_id' 

attribute  =» 

lx_arcpoa 

:  source_position,  “ 

lx_comm*nta 

;  comments; 

attribute  => 

sm_e*p_fype 

:  TYPE_SPEC, 

sm_vahj» 

:  value; 

attribute_caii  => 

as_name 

:  NAME,  —  used  for  attributes 
—  with  arguments 
—  NAME  can  only  be  attribute 

as_exp 

:  EXP; 

attribute_call  => 

lx_srcpas 

:  source_position. 

lx_commanta 

:  comments; 

attribute_call  => 

am_axp_typa 

;  TYPE_SPEC, 

sm_va/ue 

:  value; 

—  4.2  Literals 

—  Refer  to  4.4.C  for  numeric_lfterai,  string  literal. 

—  and  null_acces3. 

—  Refer  to  4. 1  for  characterjiteral 

—  The  enumeration_literal  is  represented  as  a  'used  object  id'  or  a 
—  'used  char1  whose  attributes  point  to  an  'enum  idr  or  a  f3ef_char*. 
—  See  3. 5. 1.8 


—  4.3  Aggregates 

—  Syntax  4. 3. A 

—  aggregate  ::  = 

—  (component_association  {,  component_association}) 


EXP  ::= 

aggregate  -> 
aggregate  => 

aggregate  -> 


Syntax  4.3. B 
component_association 
[choice- { I  choice) 


aggregate; 

a«_/i«f 
lx_srcpo3 
lx_comm*n1a 
sm_exp_fype 
vn_constrwrrt 
am_normaliiad_comp_3 


>  ]  expression 


Seq  Of  COMP_ASSOC; 

source_position, 

comments; 

TYPE  SPEC, 
CONSTRAINT, 

:  EXP  S; 


COMP_ASSOC 
named  =» 
named  z> 


named  I  EXP; 

a»_cbofce_s 
as  _exp 
tx_anpoa 
/x_commenfs 


CHOtCE_S, 

EXP; 

source_positton 

comments; 
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—  Syntax  4. 4. A 

—  expression  : :  - 

—  relation  {and  relation}  I  relation  {and  then  relation) 

—  I  relation  {or  relation)  I  relation  {or  elae  relation) 

—  j  relation  (xor  relation} 


EXP  ::= 

binary; 

—  only  for  short-circuit 

—  expressions;  see  3.3.4  of 

binary  => 

•s_axpf 

EXP. 

aa_binary_op 

BINARY  OP, 

as_exp2 

EXP; 

binary  => 

ix_arcpoa 

souree_posit>on, 

/x_commer»fa 

comments; 

binary  *> 

am_axpjtyp* 

TYPE_SPEC,  —  always  the 

—  of  a  Boolean  type 

sm_va/ue 

value; 

BINARY  OP  = 

SHORT_CIRCUIT_OP; 

SHORT_CIRCUIT_OP  ::  = 

and_then  1  or_else; 

and_then  => 

lx_arcpoa 

:  source_position. 

fx_commenfa 

:  comments; 

or_el«e  => 

lx_arcpoa 

:  source_position, 

!x_comments 

:  comments; 

—  Syntax  4.4.B 

—  relation  :  :* 

—  simpte_expression 

[relational_operator  $imple_expression] 

—  I  $imple_expression 

[not]  in  range 

—  j  simple_expression 

[not]  in  type_mar»c 

EXP 

membership; 

TYPE_RANGE  ::  = 

RANGE  1  NAME; 

membership  => 

as_exp 

:  EXP, 

aa_memdersfi/p_op 

;  MEMBERSHIP  OP, 

aa_fype_range 

:  fYPE_RANGE; 

membership  => 

lx_arcpoa 

:  source _posit(on. 

lx_commenfs 

;  comments; 

membership  -> 

»m_exp_fype 

:  TYPE_SPEC,  —  always  the 

—  of  a  Boolean  type 

sm.vafue 

:  value; 

MEMBERSHIP_OP  = 

in_op  I  not_in; 

m_°p  => 

ix_srcpoa 

:  source_posltton, 

/x_commenfs 

:  comments; 

not_ln  => 

/x_arcpoa 

:  source_poattion, 

/x_commenfs 

:  comments; 

I 
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—  Syntax  4.4.C 

—  simpie.expression  ::  = 

—  [unary.operator]  term  (binary  adding  operator  term) 

—  term  :  :=  factor  {multiplying.operator  factor} 

—  factor  ::=  primary  [**  primary]  I  aba  primary  I  not  primary 


—  Syntax  4.4.0 

—  primary  : :  = 

—  numaric_litaral  I  null  I  aggregate  I  »tnng_literal  I  name  I  allocator 
I  function.call  I  type_conversk>n  I  quatified.expression  I  (expression) 


EXP  NAME 

)  numenc_Uteral 
I  nult.access 
I  aggregate 
I  string.literal 
I  allocator 
I  conversion 
I  qualified 
I  parenthesized; 


—  name,  functk>n_call  (4.1,  6.4) 

—  numeric_ltteral  (below) 

—  nua  (sen  below) 

—  aggregate  (4.3) 

—  string__literat  (below) 

—  allocator  (4.8) 

—  type_conversion  (4.6) 

—  quatified.expression  (4.7) 

—  (expression)  (below) 


—  This  is  not  a  construct  in  the  Formal  Definition. 

—  See  rationale 


parenthesized  -> 
parenthesized  => 

parenthesized  => 


aa_a*P 

lx_arcpoa 

/x.commenfs 

am_exp_fype 


EXP; 

source_position, 

comments; 

TfPE_SPEC, 

value; 


numeric  literal  -> 


!x_arcpoa  :  source_po*ition , 

/x_commenfs  :  comments, 

lx_nnmr»p  :  number_rep; 

sm_exp_fype  :  TYPE.SPEC, 

am_va/ue  :  value; 

—  if  there  is  implicit  conversion  sm_exp_type  reflects  conversion; 

—  otherwise  it  references  a  universal  type 


numeric  literal  => 


string_literal  => 
string  literal  => 

nuD_access  => 
null  access  => 


lx_srcpoa 

/*_comm»ots 

tx_aymr»p 

«m_a*p_(ypa 

am_construnt 

sm_vaA«e 

!x_arcpoa 

lx_commftla 

*m_»xp_typ* 

am_ve/ue 


:  $ource_position, 
;  comments, 

:  symbol_rep; 

:  TYPE  SPEC, 

;  CONSTRAINT, 

;  value; 

;  source  .position, 
:  comments; 

:  TYPE.SPEC, 

;  value; 
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—  4.5  operators  and  Expression  Evaluation 

—  Syntax  4.5 

—  k>gical_operator  ::=  and  I  or  |  aor 

—  reiatkmai_operator  ::=  =  I  /=  |  <  |  <=  |  >  I  >  = 

—  adding  operator  M  -  I  t 

—  unary_operator  ::=  *  I  - 

—  multiplying  operator  ::=  *  |  /  |  mod  I  ram 

—  highest _precedence_operator  :  :=  «*  I  aba  |  not 

—  operators  are  incorporated  in  function  calls,  see  3.3.4  of  rationale 

—  operators  are  defined  in  Diana  refinement,  Diana_Concrete 


—  4.6  Type  Conversions 

—  Syntax  4.6 

—  type_conversion  :  :=  type_mark( expression) 


conversion  ->  ««_jTanre 

aa_axp 

conversion  =>  lx_arcpoa 

lx_comm*nta 

conversion  =>  am_exp_fype 

sm_vafue 


NAME. 

EXP; 

source_positlon, 

comments; 

TYPE_SPEC, 

value; 


—  4.7  Qualified  Expressions 

—  Syntax  4.7 

—  quallfied_expression  = 

—  type_mark* (expression)  I  type_mark*aggregate 


qualified  => 
qualified  => 
qualified  => 


as_r>ame 

as_e*p 

lx_arcpoa 

/x_cornmenfa 

sm_e*p_fype 

sm_ve/Ue 


NAME, 

EXP; 

source_position, 

comments; 

TYPE_SPEC, 

value; 


—  4.8  Allocators 

—  Syntax  4.8 

—  allocator  ::  = 

—  nee  subtype_indicetion  I  nee  quallfted_expresaion 


EXP_CONSTRAINED ; :  s  EXP  I  CONSTRAINED; 


allocator  -> 
allocator  «> 

allocator  => 


aa_axp_cooatrain+d 

lx_atxpoa 

lx_comm»nta 

am_exp_fype 

am_vaee 


;  EXP_CONSTRAINED; 
;  source _po*ition, 

:  comments; 

:  rrPE_SPEc, 

:  value; 
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—  5.  Statement* 

—  5.1  simple  and  Caspound  Statements  -  sequences  o£  Statements 

—  Syntax  5.1. A 

—  sequence_of_statements  :  :=  statement  (statement) 


STM_S  ::  = 


stm_s; 


stm_s  =>  aa_tfsf 

stm_*  s>  lx_srcpoa 

lx_commanta 


—  Syntax  5. 1 .8 

—  statement  : :  = 

—  (label)  simple_statement  I  (labal) 


STM  ::  = 

labeled; 

labeled  => 

aa_»d_s 

aa_atm 

labeled  => 

lx_srcpoa 

tx_commanta 

OEFJO  ::  = 

label_id; 

label_id  => 

lx_arcpoa 

tx_commanta 

label_id  => 

txjsymrap 

am_stm 

:  Saq  Of  STM; 

:  *ourca_po#ition, 
:  comments; 


eompound_st  element 


ID  S,  —  Saq  of  labai  id* 
STM; 

source  _positton, 
comment*; 


;  sourca_position, 

;  comments. 

:  symbol  rap; 

:  STM;  —  always  labeled* 


—  Syntax  5. 1.C 

—  simple_statement  ; ;  =  null_statement 
I  assignment_statement  I  procadura_call_sUtament 


—  I  exit_statement 


I 

-  I 

-  I 


goto_statement 

dalay_statement 

raise_statamant 


|  retum_statement 
I  entry_call_statament 
j  abort_statamant 
I  coda_statamant 


STM 


STM 


null_stm 

I  assign 

I  prooadura_ca)l 
I  exit 
j  return 
I  goto 
I  antry_call 
I  delay 
j  abort 
I  raise 
I  coda; 


—  null_statement  (5.1.F) 

—  assignment_statement  (5.2) 

—  proced u re_c*l l_st atamant  (6.4) 

—  axrt_statamant  (5.7) 

—  ratum_statamant  (5.8) 

—  goto_statement  (5.9) 

—  antry_call_*tatamant  (9.5.B) 

—  delay _statement  (9.6) 

—  *bort_ statement  (9.10) 

—  ralse_statment  (11.3) 

—  code_statement  (13.8) 


pragma; 


pragma  allowed  where 
statamant  allowed 
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—  Syntax  5. 1  .D 

—  eompound_statement  : :  = 

—  if  statement 

—  I  loop_statement 

—  j  accept_statement 


I  case_statement 
I  Mock_«tatamant 
|  select  statement 


STM 


if 

|  CIM 

|  rvamed_stm  |  LOOP 
I  Mock 

I  iCCAOt 

|  salact  I  eond_entry 


—  if_statmant  (5.3) 

—  casa_statafnant  (5.4) 

—  loop_statamant  (5.5) 

—  block_statement  (5.6) 

—  aceept_statement  (9.5.0 
timad_antry; 

—  select_statement  (9.7) 


—  Syntax  5. 1.E 

—  labal  :  :=  <<»atoe/_simple_name>  > 
—  saa  5.1.8 

—  Syntax  5.  I  P 

—  null  statement  :  :=  nui  ; 


null  stm  -> 


lx_srcpaa  :  sourca_position, 

lx_comm*nta  :  comments; 


—  5.2  !)■■  i jinannt  statement 


—  Syntax  5.2 

—  assignment_statement  : :  = 

—  vanaMe_ nama  :=  expression; 


assign  -> 
assign  => 


a«_/»an»a 

aa_axp 

lx_srcpoa 

lx_comrrmtta 


;  NAME. 

:  EXP; 

:  source _poartton, 
:  comments; 
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—  5.3  If  state— nte 


—  Syntax  5. 3. A 

—  if_statement 

—  If  condition  then 

—  sequer>ce_of_  statement* 

—  {eta*  condition  Own 

—  sequence_of_*tatements} 

—  sequence  of  statements] 

—  end  it 


if  =>  as_/isf 

if  =>  l*_arepoa 

ix_commenfs 


CONO_CLAUSE  ::: 
cond_dause  -> 
cond  douse 


cond_douse; 

os_exp_void 

ss_dm_s 

tx_vcpo« 

fx_commenfs 


:  Seq  Of  COND_CLAUSE; 
:  *ource_position, 

:  comments; 


:  EXP_VOIO,  —void  for  else 
:  STM_S; 

:  source_positfon, 

;  comments; 


—  Syntax  5.3.8 

—  condition  : :  -  boofean__expression 


—  condition  is  replaced  by  EXP 


—  5.4  Cass  state— nte 


—  Syntax  5.4 

—  cese_statement  ::  = 

—  cnee  expression  ie 

—  caae_statement_alternative 

—  {caae_statement_alternative} 

—  ca*e_*t*tement_alternattve  = 

—  when  choice  {I  choice  }  *> 

—  sequence_of_statements) 


ALTERNATIVE  S  :  :  = 

alternative.*; 

ALTERNATIVE-:  :  = 

alternative  1  pragma; 

—  pragma  allowed 

case  => 

aa_o*p 

ea_a*erna«ve_« 

EXP, 

ALTERNAT1VE_S; 

case  «* 

!x_*rcpoM 

/»_commonfs 

source_posttton, 

comments; 

altematlve_s  *> 

aa_/ls< 

Seq  Of  ALTERNATIVE; 

altemative_s  »> 

fx_srcpoa 

fx_commenfs 

souroe_positlon, 

comments; 

alternative  *> 

a#_chofce_* 

as_sfm_* 

CHOICE  _S, 

STM_S; 

ait  amative  «> 

fx.srepoa 

)<_commenfs 

souroe_posltlonl 

comments; 

where  alternative  allowed 
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—  5.5  loop  Statements 


—  Syntax  5. 5. A 

—  loop.statement  :  :  = 

—  [  tea*  '  simple.name :  ] 

—  l  tteration.scheme  ]  loop 

—  sequence_ot_statements 

—  and  loop  [/oop~simp(e_name] ; 


named.stm  => 

aa_id 

aa_atm 

named.stm  => 

ftr_srcpoa 

*x_comme/><« 

OEF.ID  = 

named_stm_id; 

named  .stm.id  s> 

lx_arcpoa 

lx_commarrta 

lx_aymr*p 

rvamed.stm.Kl  s> 

am_atm 

LOOP  ;:  = 

loop; 

ITERATION 

void; 

loop  => 

•s _rf#r«i/on 
aa_atm_a 

loop  =» 

lx_arcpoa 

lx_comnmnta 

ID.  —  always  a  *named_stm_id' 

STM;  —  loop1  or  •block1 

sourco .position, 
comments; 


;  source_posrtton, 

:  comments, 

:  symbol_rep; 

:  STM;  —  always  *nsmed_stm' 


ITERATION, 

STM_S; 

source  .position, 
comments; 
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ITERATION  ;;  = 

for  1  reverse; 

for  -> 

*s  Jd 

:  ID,  —  always 

a*_d«c/*_ranps 

:  DSCRT_RANGE; 

for  => 

fx_arcpoa 

;  source_positton , 

/x_commenfs 

:  comments; 

reverse  *> 

—Jd 

:  10,  —  always 

B4_dacrt_r*ngm 

:  DSCRT_RANGE; 

reverse  => 

tx_srcpo9 

;  sou  rce_  position. 

/x_commenfa 

:  comments; 

OEE_JO  = 

iterebon_id; 

itaration_id  => 

lx_arcpoa 

:  source ^position, 

/x_commenfa 

;  comments. 

lx_symr*p 

;  symbol  rep; 

iteration_id  => 

smjobLJvp* 

:  TYPE_SPEC; 

ITERATION  = 

while; 

while  => 

aa_#xp 

:  EXP  ; 

while  => 

lx_arcpoa 

;  source_positlon. 

lx_cofnmaf>ta 

;  comments; 

—  5.6  Block 


Syntax  5.6 
Mock_statement  :  :  = 

tb/ocfc_simple_»»ame :  ] 


declarative_p*rt] 

sequenee_ot_statements 


exception.handter 
{ except  K>n_handler}  ] 
and  [WocA_simple_n*me] ; 


—  aaa  5. 5. A  for 
Mock  »> 

Mock  *> 


aa_rfam_« 

e*_sfm_s 

aa_affsrnafJve_s 

!x_trepo» 

fx_commenfa 


ITEM  S, 

stm3, 

ALTfl&NAT1VE_S; 
source _posrtk>n, 
comment*; 
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—  5.7  Exit  statements 

—  Syntax  5.7 

—  axil  statement 

—  exit  [ loop  nama]  [w#mn  condition]; 


NAME  VO  10, 

EXP_VOIO; 

*ource_position, 
common  ts; 

LOOP;  —  Computed  ovon  whan  there 

—  is  no  nama  givan 

—  in  the  sourca  program. 


—  5. •  Return  statements 

—  Syntax  5.8  _  ,  , 

—  ratum  statement  return  [expression]; 


NAUE_VOID  = 
exit  •> 
exit  «> 
exit  => 


NAME  I  void; 

aa_name_void 

as_exp_voW 

fx_srcpos 

/x_contmenfs 

am_atm 


return 
return  => 


a*_*xp_void 

l*_arcpoa 

/x_commerrts 


EXP_VOtD; 
source _positk»n, 
comments; 


—  s.9  Goto  Statements 

—  Syntax  5.9 

—  goto_statement  goto  /aPef_name; 


goto  => 
goto  *> 


a  s_name 

lx_srcpo3 

lx_comm*nt3 


:  NAME; 

;  source_positton, 
:  comments; 
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—  6.  Subprogram 

—  6.1  Subprogram  Declarations 

—  Syntax  6.  t.A 

—  subprogram.declaratlon  :  :=  subprogram.specification; 


SUBPROG  RAM.DEF  ::=  void; 


—  for  procodura  and  function  subprogram  designator  is  ona  of  'proc.id', 

—  Yu  net  ion  .id1,  or  Mef.op’ 

—  for  entry"  subprogram  designator  is  'entry_<d' 

—  for  renaming  can  be  any  of  above  or  'enum.id*  see  3.7  in  rationale 


subprogram_dec!  => 


subprogram.ded  => 


as_d»3ign*tor 

as ./leader 
aa_aubprogram_daf 
lx_arcpoa 
lx_commanta 


DESIGNATOR, 

HEADER, 

SUBPROG  RAM.DEF ; 
source  .position, 
comments; 


DEF.ID  = 


proc.id; 


proc.id  => 
proc.id  -> 


lx_arcpoa 
Ixjcommanta 
f 'xjaymrap 
am_apac 
amjbody 
sm_Jocation 
am_atvb 
am  jurat 


source.position, 

comments, 

symbol.rep; 

HEADER, 

SUBP.BODY  OESC, 
LOCAnON, 
DEF.OCCURRENCE, 
DEF~  OCCURRENCE; 


DEF.IO 


function,  id; 


function. id  -> 
functioned  => 


lx_arcpoa 

Ixjcommanta 

lx_aymrap 

am_apac 

am_body 

amjocation 

am_atub 

am_flrat 


source,  posit  ion, 
comments, 
symbol  rep; 
HEADER. 

SUBP.BODY  DESC, 
LOCATION, 

DEF  OCCURRENCE. 
DEFZOCCURRENCE; 


DEF.OP  def.op; 


def.op  => 


def.op  => 


lx_arcpoa 

Ixjcommanta 

lx_aymrap 

sm.spec 

sm.Porfy 

amjocation 

am_atub 

amjlrat 


source .position, 
comments, 
symbol  rep; 
HEADER, 

SUSP  BODY.DESC, 
LOCATION, 

DEF  OCCURRENCE, 
OEF  OCCURRENCE; 


LANGUAGE  : :  =  argument. id; 

LOCATION  :  :=  EXP.VOIO  I  pragma.id; 

SUSP  BODY  DESC  :  Mock  I  stub  I  instantiation  I 

FORMAL  SUBPROG  DEF  I  rename  I  LANGUAGE  I  void; 


—  ‘pregme.kT  and  'argumant_nf  only  occur  in  the  predefined  environment 
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—  Syntax  6.1.8 

—  subprogram_specificatton  : :  = 

—  procedure  identifier  [formal_pert] 

—  I  function  designator  [formal_part]  return  type_mark 

—  designator  :  =  identifier  I  operator_symtool 

—  operator_*ymbol  :  :=  atnng  literal 


HEADER  procedure; 

HEAOER  :  :=  function; 


procedure  -> 
procedure  »> 


aa __param_3 

lx_srcpoa 

/x_commenfa 


:  PARAM_S; 

:  source_po*ition, 
:  comments; 


function  => 


function  -> 


ss_pers#n_a 

ss_nsme_vo»d 

lx_arcpoa 

lx_comm*nla 


;  PARAM_S, 

:  NAME_VOID; 

—  void  In  case  of  instantiation 
;  souree_position, 

:  comments; 
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—  Syntax  6.1.C 

—  \  j- 

—  (paremeter_specification  {;  parameter_ specification}) 

—  parameter  specification  :  := 

—  tderrtifierjist  :  mode  type_mark  [:  =  expression] 

—  mode  : :  =  [in]  I  in  out  I  out 


PARAMOS 

:  := 

param_s; 

param_s  - 

> 

aa_«af 

param_s  = 

lx_srcpoa 

fx_commenfa 

PARAM  : : 

= 

in; 

in  => 

aa_fd_a 

aa_name 

aa_axp_votd 

in  => 

lx_arcpoa 

lx_commanta 

lx_datautt 

PARAM  :  : 

S 

in_out; 

PARAM  :: 

s 

out; 

in_out  => 

as_/d_s 

aa_name 

aa_«xp_void 

m_out  s> 

lx_arcpos 

)x_comments 

out  *> 

aa_fd_s 
as _nam* 
•s_exp_vo»d 

out  => 

lx_arcpoa 

lx_commmnta 

DEF_IO  ; 

:  = 

in _ id ; 

in_id  -> 

lx_arcpoa 

lx_comm*nta 

lx_aymrap 

in_id  *> 

am_obi_typa 

amjndjaxp 

am_tlrat 

OEFJD  : 

:s 

ln_out_kl  1 

in_out_ld 

s> 

fx_srcpoa 

fx_commenfs 

lx_symrep 

in_out_id 

*> 

am_obt_typa 
am _t ir at 

out_id  *> 

lx_arcpoa 

lx_commenfa 

out_id  => 

te_ay mrep 

am_obl_typa 

am_tirat 

Seq  Of  PARAM; 
source  _position, 
comments; 


ID_S,  —  always  a  sequence  of  'in^d1 
NAME, 

EXP_VOiO; 

source_position, 

comments. 

Boolean; 


ID  S,  —  always  a  sequence  of  1n_out_id' 
NAME, 

EXP_VOIO;  —  always  void 

source_position, 

comments; 

ID  S,  —  always  a  sequence  of  ‘out_id* 
NAME, 

EXP_VOID;  —  always  void 
source _position, 
comments; 


source_position, 

comments, 

symbol_rep; 

TYPE  SPEC, 

EXP_VOID, 

DEF_OCCURRENCE; 


source_position, 

comments, 

symbol_rep; 

TYPE  SPEC, 
DEP_OCCURRENCE; 

so  urce_  position, 

comments, 

symbot_rep; 

TYPE  SPEC, 
DEF_OCCURRENCE; 
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—  6.3  Subprogram  Bodies 


—  Syntax  6.3 

—  subprogram_body  :  := 

—  subprogram_spacificatlon  t* 

—  [daclarativa  part] 

—  bagin 

—  saquanca_ot_statamanta 

—  [aneapMon  ~ 

—  axcaptk>n_handlar 

—  {axcaption_handlar}] 

—  and  [designator]; 


BLOCK_STUB  :  block; 

subprogram_body  =>  »3_d»aignalof 

aa_Aaadar 

*s_block_atub 

subprogram_body  =>  lx_arcpoa 

lx_comimnta 


:  DESIGNATOR,  —  ona  of  "proc_id\ 
—  function  id*  or  'daf  op*“ 

;  HEADER, 

;  BLOCK_STUB; 

;  sourc«_po*itiont 
:  commanta; 
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—  6.4  Subprogram  Calls 


—  Syntax  6.4 

—  procedure_call_statement  :  :  = 

—  procetfure.name  [actu*l_parameter_part]; 

—  Hmct*on_c*ll  ::  = 

—  iunciicn _n*rrm  [  actual_parameter  .part] 

—  actual_parameter_part  :  :  = 

—  (pararneter.aasoctation  {,  parameter.assoctation}) 

—  parameter.associatlon  ::= 

—  [formar_parameter  =>]  actual .parameter 

—  formal  .parameter  : pv*m*if_s  impie.name 

—  actual  .parameter  ::= 

—  expression  I  variaMe.neme  I  type.marktvariep/e.name) 


procedure_call  => 

aa.name 

NAME, 

aa.peram.assoc.a 

PARAM.ASSOC.S; 

procerfure.cafl  => 

/x.arcpos 

source_position. 

lx_comm*nta 

comments; 

procedure.call  => 

am_normaliz9d_param 

_s  :EXP_S; 

hmction.call  => 

as_nama 

NAME, 

*a __param__aaaoc_3 

PARAM.ASSOC.S; 

function.call  => 

lx_arcpoa 

source_position. 

lx_commmts 

comments; 

function  .call  => 

sm.exp.fype 

TYPE  SPEC. 

am_v»kM 

value. 

3/n_normaliz*d_j)aram 

_s  :  EXP_S. 

lx_pr*ttx 

Boolean; 

PARAM.ASSOC 

EXP  1  aaaoc; 

aaaoc  -> 

aa^dasignator 

DESIGNATOR, 

aa.actuaf 

ACTUAL; 

aaaoc  => 

lx_arcpoa 

source,  position, 

fx.commenfa 

comments; 

ACTUAL  :  :  = 

EXP; 
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—  7.  Packages 

—  7.1  Package  Structure 

—  Syntax  7.1. A 

—  package_dedaration  :  :=  package_specification; 


p*ckxqe_dec)  => 
pacfcage_deci  => 


aa_jd 

aa_package_def 
lx_srcpoa 
lx  comment* 


10,  —  always  'packagejd' 

PACKAGE_DEF; 
source  _positlon, 
comments; 


DEF_ID  ::  = 
package_id  -> 


package_id  => 


PACK  BODY_DESC::  = 


package_id; 

source_positk>n, 
comment*, 
symbol  rep; 

PACKAGE  SPEC, 

PACK  BOOY_OESC, 
EXP_VOIO, 
DEF_OCOJRRENCE, 
DEF_OCCURRENCE; 

block  I  stub  I  rename  I  instantiation  |  void; 


ix_srcpos 

lx_commenta 

lx_symrep 

am_ap#c 

smjoody 

sm_edt/reas 

sm_stub 

am  first 


—  Syntax  7.1.0 

—  pack*ge_specification  ; ;  s 

—  package  identifier  is 

—  {basic_declaratlve_item} 

—  [private 

—  [bastc_declarati ve_item }  ] 

—  and  [pac*age_simple_name] 


PACKAGE_SPEC 
PACKAGE_OEF  ; 

peckage_spec  => 

package_spec  => 


package_spec; 

package_spec; 

a«_decl_s1 

aa_dect_a2 

Ix^srcpoa 

lx_comments 


DECL_S,  —  visible  declarations 

DECL~S;  —  private  declarations 

source  _position, 
comments; 


0ECL_S  :;=  decl_s; 


decl_s  => 
dect_s  -> 


eejbi 

lx_srcpos 

lx_commenta 


Seq  Of  DECX; 

source_po*itk>R 

comments; 
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—  Syntax  7.1.C 

—  package_body  :  := 

—  package  body  pacftage_simple_name  la 

—  [  deciar*trve_part  ] 

—  [begin 

—  sequence_of_statements 

—  r  aumhon 

—  exception_handler 

—  {exception_handler}]] 

—  and  [pac*age_simple_name] ; 


package_body  => 
packege_body  => 


»a_id 

aa_block_3iub 

lx_arcpoa 

lx_commanta 


ID.  —  alwaya  *peckage_id' 

BLOCK_STUB; 

source  _poaition, 

comments; 


—  7.4  private  Type  and  Deferred  Constant  Declarations 


—  Syntax  7. 4. A 

—  pnvate_type_dedaration  ::=  „  .. 

—  type  identifier  [diacriminant_pert]  ta  [Nmttnd] 


TYPE  SPEC  private; 

TYPE~SPEC  l_private; 

private  ->  lx_arepoa 

lx_commanla 

private  =»  am_diacnminanta 

I  private  =>  lx_arcpoa 

“*  ix_comm*nta 

I _pnvate  =*  sm_diacriminanta 

DEF_ID  ; :  =  private_type_id  I 

private  type_id  =>  lx_3rcpoa 

lx_commanla 

lxZ.rtm*p 

private_type_id  ->  am_fype_apec 


l_prtvata_type_id  =>  lx_arcpoa 

Ixjcommanta 

lx_3ymrap 

l_prtvate_type_id  =>  am_fype_apec 


—  Syntax  7.4.8 

—  deferred_conatant_deciaration  : :  = 

—  identifierjist  :  toMM  type_marti; 

deferred_constant  *>  aa_id_a 

aa_name 

deferred  constant  ->  lx_arcpoa 

Ixjeommmta 


:  source_posrtion, 

;  comments; 

:  D$CRMT_VAR_S; 

:  source _position, 

:  comments; 

;  DSCRMT_VAR_S; 

l_private_type_id ; 

:  source_positk>n, 

:  comments, 

:  symbol_rep; 

;  TYPE  SPEC; 

—  Refers  to  the  complete 

—  type  specification  of  the 

—  private  type. 

—  See  3. 4. 2. 4  of  ratk.  tale. 

:  source_positionI 
;  comments, 

;  symbol_rep; 

:  TYPE_SPEC; 

—  Refers  to  the  complete 

—  type  specification  of  the 

—  limited  private  type. 

—  See  3. 4. 2. 4  of  rationale. 


ID  S,  —  sequence  of  ,conat_id’ 
NAME; 

source_positton, 

comments; 
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—  e.  visibility  Rules 

—  8.4  Oae  dam— e 


Syntax  8.4 
un  clausa 


UN  => 
UN  -> 


:=  un  pac*age_n ama  {,  pac*age_name} ; 


a«_//af 

lx_arcpoa 

/x_commenf« 


Declarations 


:  Sap  Of  NAME; 

;  source_positk>n, 
;  commanta; 


Syntax  8.S 

renaming_deciaration  : :  = 

identifier  :  typ*_marV 
I  Idantiflar  ;  exception 
1  package  Identifier 
j  subprogram_specification 


ob/ecf_name; 
except/or)_name; 
pa c*age_name; 
subprogram  __or__enfry_name; 


—  Sea  Section  3.7  of  rationale  for  discussion  of  renaming 


OBJECT_DEF  :;  = 
EXCEPTION  DEF  :  ;  = 
PACKAGE  DEF  :  :  = 

subprooSam_oef 


rename  => 
rename  => 


rename; 

rename; 

rename; 

rename; 


a«_name 

lx^9rcpos 

/x_commen/s 


NAME; 

source_posit)on, 

comments; 
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—  9.  Tasks 

—  9.1  Task  Specifications  and  Task  Bodies 


—  Syntax  9.  t.A 

—  ta*k_daciaration  :  :=  taak__specihcation; 

—  task  specification  :  := 

—  task  {type]  identifier  [it 

—  {entry_dedaratlon} 

—  {representation_eiauae} 

—  and  [fa*A_simple_name]  ] 


—  see  3.3  for  task  type  declaration 

TASK  DEF  = 

task_spec; 

taak_ded  *> 

as_id 

task_ded  *> 

lx_vepoa 

/x_commen/« 

TYPE_SPEC  ::  = 

task_spee; 

task_spec  => 

a*_dee/_s 

taak_spec  => 

lx_vcpoa 

lx_comm*nt3 

taak_spec  -> 

amjbody 

am_idclr*aa 

3m_3torag9_3JZ9 

10,  — always  a  var  Id 

TASK_DEF; 
source  _positlon, 
comments; 


:  DECL_S; 

;  sourca_positk>n> 

:  comments; 

;  BL0CK_STU8_V0I0 ,  —  Void  only 

—  in  the  presence 

—  of  separate  compilation. 
—  See  3.5.5  of  rationale. 

;  EXP  VOID, 

:  EXP  VOID; 


0LOCK_STUB_VO!O  :  block  I  stub  I  void; 


—  Syntax  9. 1.B 

—  task_body  : ;  = 

—  task  body  fas*_simple_name  is 

—  [declaratlwe_part] 


t 


sequence_of_statements 


excepbon_handler 
{exceptk>n_handler}  ] 
end  [fasfc_simpte_name]; 


task_body  -> 
task_body  => 


as_Wock_sfub 

tx _ SfCp<>4 

/x_commenft 


ID,  —  always  •task_body_id, 

BLOCK_STUB; 

sou  roe_pos)t  ion , 

comments; 


OEFJO 


taak_body_id; 


task_body_ld  => 
tasfc_body_ld  *» 


lx_trcpo4 

/x.commenfs 

lM_aymrmp 

am_fype_spec 

am_ftody 

am_«rsf 

sm.sfub 


souree_positton, 
comments, 
symbol  rap; 

TYPE  SPEC, 

SLOCK  sms_vofo, 
DEF  OCCURRENCE, 
DEF  OCCURRENCE; 


Ada  Section  8.5 


Page  66  /  Section  2 


Diana  Reference  Manual 


—  9.5  Brtxiss,  Entry  calls  and  Accept  statements 


—  Syntax  9. 5. A 

—  entry_dedaration  ::  = 

—  entry  identifier  [  (di«crete_range)  ]  [formal_part); 


—  entry  uses  *ubprogram_decl,  see  6.1 


HEADER  entry; 

DSCFT_RANGE_VOID  : :  =  DSCRT__RANGE  I  void; 


entry  => 
entry  *> 


M3_d3crt_rtng9_vo/d  : 
M_p*ram_a 
lx_arcpoa 
lx_comm*nta 


DSCRT  RANGE  VOID. 
PARAMOS;  ~ 
source_po$itton, 
comments; 


DEF  10  : :  = 


entry_kl; 


entry_id  => 
entry_id  => 


lx_arcpoa 
lx_commanla 
lx_aymnp 
sm_spe c 
sm_ad  cf re  aa 


source__  position, 
comments, 
symbol  rep; 
HEADER, 
EXP_VOID; 


—  Syntax  9.5.8 

—  entry _cell_st«tement  :  :=  entry _name  [actual_paremeter_part]; 


entry _call  =>  a«_name  :  NAME,  —  indexed  when  entry  of  family 

“  aa_param_a«aoc_s  :  PARAM_ASSOC_S; 

entry _call  =>  lx_arcpoa  :  souroa_jpoattion, 

lx_commanta  :  comments; 

entry_call  =>  sm_normaliz*d _p*ram^3  :EXP_S; 


—  Syntax  9.5.C 

—  aocept_statement  = 

—  accept  enfry_timpie_name  [  (entry_index)  ]  [formal_part]  [do 

—  sequence_of_statementa 

—  end  [  entry _*im  pie_name  ]  ] ; 

—  entry_index  : :  =  expression 


accept  *> 


accept  => 


as_/>eme 

as_param_s 

aa_a»m_s 

lx_arcpoa 

lx_eommenfe 


NAME. 

PARAM  S, 
STM_S“ 
*ource_po«rtion 
comments; 


—  9.6  Delay  Statements,  Duration  and  Tima 

—  Syntax  9.6 

—  daiay_statament  :  :=  delay  simpia_axprassion; 


deiay  *>  as_exp  :  EXP; 

daisy  »>  lx_arcpoa  :  aource_position, 

fx_commenfa  :  comments; 
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—  9.7  select  Stats 


—  Syntax  9.7 

—  select_statement  :  :=  selecttve_weit 

—  I  condltional_entry_cail  I  timed_entry_eall 


—  see  below 

—  9.7.1  selective  Malts 


—  Syntax  9.7. 1. A 

—  seteetive_wait  = 

—  select  alternative 

—  {or 

—  select_altemative} 

—  sequence_of_stat  aments] 


select  => 


select  => 


aa_aW*cl_c/ou»a_s 

(x_arcpoa 

fcr_commenfs 


:  SELECT_CLAUSE_S, 
:  STM_S; 

:  sou  ree_positK>n , 

:  comments; 


SELECT  CLAUSE_S  select  ciause_»; 

select_3euse_s  s>  aaJiaT  :  Seq  Of  SELECT_CLAUSE; 

select_dause_s  =>  !x_arcpoa  :  *ourca_po*rtton, 

”  tx_comrnania  ;  comments; 


—  Syntax  9.7. 1.8 

—  select rve_altemat>ve  ; :  = 

—  [whan  condition  =>] 

—  setective__weit_altemative 

—  selective^ wait_altematlve  : :  *  accept _altemative 

—  I  delay _alter native  I  terminate_altornatlve 

—  accept_aitematlve  accept_statoment  [ sequence_of_ statements) 

—  delay _alt amative  :  ;*  dalay_statemerrt  [sequence_ot_statements] 

—  terminate_artemattve  ; :  *  tomOneto; 


SELECT  CLAUSE 
SELECT_CLAUSE 

saloct^dauee  => 

setoct_dauso  => 

STM 

terminate  => 


selact_dause 

pragma; 

sa_exp_void 

aa_stm_s 

lx__srcpoa 

rtr_eommenfa 

terminate; 

fx.srcpos 

/s-commonfa 


—  pragma  allowed  where  alternative  allowed 

:  EXP_VO», 

:  STM_S; —  first  stm  Is  aooept  or  delay 
;  source_posltion> 

:  comments; 


:  source_posftlon, 
;  comments; 
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—  9.7.2  Conditional  Entry  calls 


—  Syntax  9.7.2 

—  oondKional_antry_call  :  :  = 


antry_caH_atatamant 
[  aaquan©a_of_atatamanta] 

aaquanca_of_statamanta 


cond_antry  => 
cond_wtry  => 


M_9tm_a2 

lx_arcpo* 

lx_commfUa 


STM  S, —  Hrat  atm  it  antry_call 
STM~S; 

aourca_poaitton, 

commanta; 


9.7.3  Tljaad  Entry  Calls 


Syntax  9.7.3 
timad_antry_call 


antry_call_atatnmant 

[aaquanca_of_atatamanta] 

dalay_attamativn 


timad_antry  =>  a«_*fm_af 

aa_sfm_*2 

timad_antry  =>  lx_arcpos 

lx_commants 


STM__S. —  Hrat  atm  ia  antry_call 
STM_S;  —  Hrat  atm  la  dalay 
aourca_poaitk>n, 
comments; 


—  9.10  Abort  3tatinta 

—  Syntax  9.10 

—  abort_atatamant  :  :=  abort  taa*_nama  {.  tas*_name); 


NAME_S 

nama_a  => 
nama_a  => 


abort  *» 
abort  *> 


nama_a; 

««_//*# 

lx_arepoa 

>x_commanfa 


aa_/»ame_a 

lx_srcpot 

lx_comm*rrta 


Saq  Of  NAME; 

aourca_poaltlon, 

commanta; 


NAME_S; 

aouroa_positlon, 

commanta; 


-  v.r 


I 
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—  10.  Program  Structure  and  Ccaylletlon  Issues 

—  10.1  Caavllatlon  Unit*  -  Library  Units 

—  Syntax  10.  t. A 

—  compilation  {oompMatlon_umt) 


COMPILATION  compilation; 

compilation  *>  ss_Jiaf 

compilation  *>  /x.arcpoa 

lx_commtXa 


—  Syntax  10.1.8 

—  comp4labon_unit  • :  = 

—  context_dause  library_unrt  I  contaxt_dauaa  *econd*ry_unit 

—  Ilbrary_unit  :  :* 

—  aubprogram_dederation  I  pacfcage_dedaratton 

—  I  generic_dedaration  j  genencjnstantiation 

—  I  subprogram_body 

—  seeondary_onit  : :  *  Mbrary_unlt_body  I  subunit 

—  llbrary_unit_body  : :  *  subprogram_body  I  peckage_body 


Saq  Of  COMPJJNIT; 

source_position, 

comments; 


COMPJJNIT  :  ;s  compjinit; 

UNTT_BOOY  :  :*  packagejxxfy  |  peckage_decl  I  subunit  I  generic 

I  subprogram_body  I  subprogram_ded  I  void; 

—  UNIT  BODY  is  void  only  whan  comp  “unit  consists  of  only  pragmas 


PRAGMA  S  :;s 

pragma_s; 

pragma_s  => 

as_//«f 

pragma_s  -> 

lx_srcpox 

/x_commenfs 

comp_unit  *> 

aa_confoxf 

n_ornt_p<xty 

aa_pragma_s 

compound  => 

lx_srcpo» 

/x_commenfa 

CONTEXT_ELEM 

pragma; 

—  Context  Clauses  -  With  Clauses 


:  Saq  Of  PRAGMA; 

:  source _positton, 

:  comments; 

:  CONTEXT. 

:  UNIT_BO0Y, 

;  PRAQMA_3;  —  extension  to  FO. 
:  source _position. 

;  comments; 

—  pragma  allowed  in  clausa 


—  Syntax  10.1.1.  A 

—  context_ciause  :  :=  {wtth_d«use  {uso_dau»e}} 


:  Saq  Of  CONTEXT  _EL  EM; 
:  source_posrtion, 

:  comments; 


CONTEXT  ELEM  :  uaa; 

CONTEXT  contest; 

contest  *>  ss_H«f 

contest  >>  tx_arcpot 

>x_commonfa 
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—  Syntax  10. 1.  t.B 

—  with_dsuse  with  und_simpte_name  {,  «/n«t_simple_neme); 


CONTEXT_EL£M  :  :=  with; 

with  =>  ee_/ist 

with  ->  !x_vcpo* 

lx_cotnm*n(* 


—  10.2  Subunit*  of  Compilation  Onits 

—  Syntax  10. 2. A 

—  subunit  :  :  = 

—  soporsto  ( p*r*nt_umt_ name )  proper_body 


subunit  -■>  ss_nsme 

M_awbumt Jbody 

subunit  =>  tx_arcpoa 

lx_comm*nla 

SUeUNIT_aoor  :  :  =  subpcogram_body  I 


—  Syntax  10. 2.  B 

—  body_stub  : :  = 

—  *ubprogram_speciti€*tton  Is  separata; 

—  I  portage  body  p*cA*v*_simpio_n*mo  Is  separate; 

—  I  task  body  fsaA_simpie_n*fne  is  separate; 


:  NAME, 

:  SUBUNIT_BOOY; 

:  sourco_positK>n, 

:  comments; 

pscksge_body  I  task_body; 


Soq  Ot  NAME; 
source _posttion, 
commonts; 


BLOCK_STUB  :  :*  stub; 

stub  =>  lx_srcpox  :  *ourco_po*rtk>n, 

/x_commonfs  ;  commonts; 

—  li.  Baoeptiow 

—  11.1  Exception  Declaration* 

—  Syntax  11.1 

—  exceptton_deci«rstk>n  : ;  ~  identiflerjist  :  seosptlon; 


EXCEPT10N_0eF  :;=  void; 


exception  *> 
exception  »» 


es_>d_s 

as_exceptton_def 

lx_arcpoa 

/x_comments 


10  S,  —  ' except ton_Kr  sequence 

EXCEPOON_OEF; 

source  _posrtion, 

comments; 


OCF_IO 

excepbon_id  *> 
exception_id  »> 


exception  _id; 

fx.srcpos 

^.comments 

lx_symr*p 

sm_excepAon_der 


source_positton, 
comments, 
symbol  rep; 
EXC€PffoN_OEF; 
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—  11.2  exception  Handlers 


—  Syntax  11.2 

—  exception_handter  :  :  = 

—  when  exceptton_choice  { I  axceptlon_choice}  -> 

—  aaquence_ot_atatementa 

—  •xceptlon_choice  : :  =  •xc*pt/on_name  |  othei 


-  5.4.  5.6,  3. 7.3.8 

—  11.3  Raise  Statements 

—  Syntax  11.3 

—  raiae_atatement  raiae  [•xcept/on_name]; 


raiae  =>  a«_name_v<wd 

raiaa  *>  lx_3rcpoa 

lK_commfit * 


:  NAME_VOtO; 

:  aource_po*itk>n , 
:  commenta; 


—  12.  Generic  Program  units 

—  12.1  Generic  Declarations 


—  Syntax  12.1.  A 

—  generic_dedaration  ::=  genenc_speciftcatlon; 

—  generic_spec>ftcation  :  :  = 

—  generic_formal_part  aubprogram_apecitication 

—  I  generic_»ormal  jmrt  package.apeciftcatton 


QENERtC_HEADER  :  :  = 
generic  => 

generic  => 

DEF_ID 
genertc_id  => 

generic_id  => 


procedure  I  function 
aa_Jd 

aa _generfc_param_a  : 

•»_pener*c_/Madar 

lx_ircpoa 

fx_commonft 

genertc_id; 

lx_*ymr*p 
lx_$rcpo* 
lx_comm*nta 
em_goneric_param_4 : 
am.apac 

sm_bo&Y 

rnnjtktt 

am_afvP 


I  pechage_apec; 

ID,  —  •generic_id, 
GENERIC  PARAM  S, 
GENERtC_HEADER; 
aource_poaition, 
commenta; 


aymbd_rep, 

aource_poaition, 

commenta; 

GENERIC  PARAM  S, 
GENERIC  HEADER, 

block_sTub  VOIO, 
OCF  OCCURRENCE, 
D£F_ OCCURRENCE; 
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—  Syntax  12. 1.8 

—  generic.formal.part  : :  *  generic  [generic_parameter_dedaration} 


GENERIC.PARAM.S  ;  ;s  generic_param_s; 

generic .param.s  =>  aa.Mof  :  Seq  Of  GENERIC.PARAM; 

generic_param_s  *»  /x.arcpoa  :  souree_posrtiofl, 

/x.commenfs  :  comments; 


—  Syntax  12. 1.C 

—  generic.parameter.dedaration  ; :  = 

—  identlfter.list  :  [M  [out]]  type.marii  [ ;=  expression}; 

—  I  type  identifier  I a  generic,  type.deflnitlon; 

—  |  prfvate.type.dedaration 

—  I  with  subprogram.speclflcatton  [la  name]; 

—  I  with  aubprogrem.specifteatlon  [la  <>]; 


GENERIC.PARAM  :  :=  in  I  In.out  I  type  |  subprogram.ded; 
SU0PROGRAM.DEF  FORMAi._SU8PROG_DEF; 

FORMAL.SU8PROG.OEF  NAME  I  box  I  no.default; 

box  -■>  lx_arcpoa  :  source_posibon. 

/x.commenfs  ;  comments; 

no  default  =>  /x.arcpoa  :  source.oosition, 

"  /x.commenfs  :  comments; 


—  Syntax  12.1.0 

—  genene_type_deflnitlon  ; ;  = 

—  (<>)  I  range  <>  I  digits  <  >  I  delta  <> 

—  I  array. type.definltlon  I  access. type.definitlon 


TYPE  SPEC 
FORMAL.TYPE.SPEC 

formal.dscrt  »> 
formal.ftxed  *> 
formal.float  *> 
formal.tnteger  *> 


FORMAL.TYPE.SPEC; 

::  *  formal.dscrt  —  (<  >  ) 

I  formal.lnteger  —  range  <> 

I  formal~fixed  —  delta  <  > 

I  formal.float;  —  digits  <> 

fx.srcpoa  :  so  urea  position, 

/x.commenfs  ;  comments; 

/x.arcpoa  :  source  position , 

/x.commenfs  ;  comments; 

/x.are pot  :  souree_positlon, 

/x.commenfs  ;  comments; 

/x.srcpos  :  aource_positlon , 

/x.commenfs  :  comments; 
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—  12.3  Generic  instantiation 


—  Syntax  12.3.A 

—  generic_instantiation  : :  = 

—  peahage  identifier  la 

—  new  gener»c_pae*age_name  [generic_actual _pert]; 

—  I  procedure  identifier  la  ~ 

—  new  generic_procedure_name  [generic  actual  part]; 

—  I  function  identifier  la  " 

—  new  gener»c_funcf/oo_name  [generic_actuat_part]; 

—  ge**enc_actuei_part  : :  = 

—  <genenc_aseociation  {,  generic_a**octation)) 


—  See  3.6  of  rationale  for  diacuaaion  of  instantiation 
SU8PR0GRAM_0EF  :  :=  instantiation; 

PACKAGE_OEF  :  :=  inatantiation; 

QENERIC_ASSOC_S  :  ;=  generie_assoc_«; 

generic_assoc_s  »>  aa_liat  :  Seq  Of  GENERIC_ASSOC; 

generic_assoc_s  *>  lx_srcpca  :  source_position, 

lx_comm*nta  :  comments; 

instantiation  a«_name  :  NAME, 

a«_generic_aaaoc_s  ;  QENERIC_ASSOC_S; 
instantiation  =>  lx_arcpoa  :  source _positkm, 

lx_commanla  :  comments; 

instantiation  =>  sm_dec/_s  :  DECL_S; 


—  Syntax  12.3.8 

—  generic_associatton  :;a 

—  [generic_formal_perameter  =>]  generic_actual_parameter 

—  genertc_formal_parameter  ; ;  =  paramefer__simpie_name  I  operator_symbol 


QENERIC_ASSOC  :  :=  assoc; 


—  Syntax  12. 3.  C 

—  generic_ actual _perameter  ;  =  expression  I  vari*bl»_n  ame 

—  I  au6program_neme  I  enfry_name  |  type_mark 


GENCR1C_ASS0C  ACTUAL; 
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—  13.  Representation  Clauses  and 

—  lepls— intafcion  Dependent  Vestures 

—  13.1  Representation  clauses 


—  Syntax  13.1 

—  repcesentation_dause  : :  = 

—  type_representation_clause  I  addresa_clause 

—  typ*_rapf**#nt»tion_cl»us*  :  :=  length_clause 

—  I  enumeratk>n_representation_clause  I  record_repre*antatlon_cfau«e 


REP 


*<mple_rep 

I  addrata 
I  racord_rap; 


—  length_clause  and 

—  enum«ration_representation_clause  (13.2) 

—  addresa_clauao  (13.5) 

—  record_representatlon_clauso  (13.4) 


—  13.2  langth  Clause 

—  13.3  Bm— ration  Representation  Clauses 

—  Syntax  13.2 

—  Iengtti_clause  for  attribute  uaa  simple_expreasion; 


—  Syntax  13.3 

—  enumeratk>n_representation_clauM  : :  = 

—  lor  1ype_simple_name~uae  aggregate; 


simple_rep  => 
aimple_rep  => 


aa_name 

aa_exp 

lx_arcpoa 

lx_comm»nta 


NAME. 

EXP; 

source_position, 

comments; 


13.4  Record  Representation  Clauses 


—  Syntax  13. 4. A 

—  reeord_repr esentation_clau$e  ; ;  = 

—  lor  (ype_»mple_name  uaa 

—  record  [allgnment_ciause] 

—  {component_dause} 

—  end  record; 


—  allgnment_clause  =  at  mod  sta«c_simple_expresaion; 


ALIONMENT  ;  ;  = 
alignment  »> 


record_rep  -> 
racord_rap 


alignment; 

ae_pragma_s 

aa_exp_vo#d 


PRAGMA  S,  —  pragma  allowed  in  clause 
EXP_VOIO; 


e*_neme 

aa_comp_rep_a 

tx_arcpo* 

lx_commenfa 


NAME. 
AUGNMENT, 
COMP_REP_S; 
source  ^position, 
comments; 
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—  Syntax  13.4.8 

--  component_clause  : : » 

—  componenf_simoie_name  at  static_simple_expression  rang*  sfaf<c_renge; 


COMP  REP  S  = 

comp_rep_s; 

COMPARER  = 

comp_rep; 

COMP_REP  = 

pragma; 

—  pragma  allowed  in 

comp_r*p_s  => 

as_lisf 

Seq  Of  COMP_REP; 

comp~rep_s  => 

lx_arcpoa 

source_position. 

lx_corrm«nia 

comments; 

comp_r«p  => 

aa_nama 

NAME, 

aa_axp 

EXP. 

aa_range 

RANGE; 

c°mp_rep  => 

lx_arcpoa 

source_position. 

lx_comm«nta 

comments; 

—  13. 5  Address  Clauses 

—  Syntax  13.5 

—  address_clause  ; :  =  for  simple_name  um  at  simple_expression; 


address  => 
address  => 


as 

aa__9xp 

lx_srcpoa 

lx_comm9nta 


NAME. 

EXP; 

source_position, 

comments; 


—  13.8  Machine  Code  Insertions 

—  Syntax  13.8 

—  code_statement  : :  -  type_mark'record_aggregate; 


code  => 
code  -> 


■s _nmma 
aa_»xp 
lx_arcpoa 
lx__comm*nta 


NAME. 

EXP; 

source_position 

comments; 


—  14.0  Input-Output 

—  I/O  procedure  calls  are  not  specially  handled.  They  are 

—  represented  by  procedure  or  function  calls  (see  6.4). 
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—  Predefined  Plana  eut  i  1 i  sMexrt 

—  sm  Appendix  I  of  this  manual 


OEPJO  ::  = 
ARGUMENT  ::= 

attr_id  -•> 

TYPE.SPEC  :  := 

umversaMnteger  -> 
umversal_fixed  => 
unrversal_real  -> 

argum«nt_id  => 

pregma_id  => 
pragmaid  => 


attr.id  I  pragma.id  |  ARGUMENT; 
argument.id; 

fx.symrap  :  symbol.rep; 

universal  .integer  I  unrversal_ftxed  I  untverssl.resl; 


tx_symrap 

aajist 

/x.symrep 


:  symbol.rep; 

:  Seq  Of  ARGUMENT; 
:  symbol_rep; 


End 


t 
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Structure  Diana_Concrete 
Refines  CXane  Is 


Refined  Diana  specification 


Version  of  11  February  1983 


For  source_position 
For  symbol_rep 
For  value 

For  operator 
For  number_rep 
For  comments 


Use  USERPK .  SOURCE_POSITiON; 

—  defines  source  position  in  original 

—  source  program,  used  for  error  messages. 

Use  USERPK.  SYMBOL_REP; 

—  representation  of  identifiers, 

—  strings  and  characters 

Use  USERPK.  MACHINE_VALUE; 

—  implementation  defined 

—  gives  value  of  an  expression. 

—  can  indicate  that  no  value  is  computed. 

Use  USERPK. OPERATOR; 

—  enumeration  type  for  all  operators 
Use  USERPK. NUMBER_REP; 

—  representation  of  numeric  literals 
Use  USERPK. COMMENTS; 

—  representation  of  comments  from  source  program 


This  defines  the  external  representations 


For  symbo!_rep 


For  number_rep 


For  operator 


For  value 


Use  External  String; 

—  the  external  representation  of 

—  symbol_rep  uses  IDL  basic  type  string. 
Use  External  String; 

—  the  external  representation  of 

—  number_rep  uses  IDL  basic  type  string. 
Use  External  OP_CLASS; 

—  the  external  representation  of  operator 

—  uses  the  private  type  OP_CLASS 
Use  External  VAL_CLASS; 

—  the  external  representation  of  values 

—  uses  the  private  type  VAL_CLASS 


1 
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—  OP_CLASS  is  «n  •numeration  class  that  defines  the  Ada  operators 

—  Syntax  4.5 

—  iogical_operator  : :  =  and  I  or  I  aor 

—  ralationai_oparator  :  :=  =  I  /=  I  <  I  <=  I  >  I  »= 

—  adding  operator  : :  =  ♦  I  -  |  & 

—  unary_operator  : :  =  *•  I  - 

—  multiplying  operator  : :  =  *  |  /  |  mod  I  ram 

—  highest_precadanca_oparator  :  :=  **  |  aba  I  not 


OP  CLASS  = 


and 
or 
xor 

•d 

no 


—  xor 

—  /- 


It  —  < 

la  —  <  = 

gt  —  > 

ga  —  >  = 

plus  —  ♦ 

minus  - 

cat  —  & 

unary_plus  —  ♦ 

unary_minus  - 

abs  —  aba 


1  not 

— 

not 

1  mutt 

— 

* 

1  dtv 

— 

/ 

1  mod 

— 

mod 

1  rem 

— 

rom 

1  exp; 

** 

and  =>  ; 

or  ->  ; 

xor  =>  ; 

eq  =>  ; 

ne  =>  ; 

It  =>  ; 

le  =>  ; 

gt  =>  ; 

ge  ; 

plus  ->  ; 

minus  => 

; 

cat  =>  ; 

unary_plus  ->  ; 

unary  minus  => 

;  abs  =>  ; 

not  =>  ; 

mult  =>  ; 
exp  =>  ; 

dlv  =>  ; 

mod  =>  ; 

rem  => 

—  VAL_CLASS  is  a  class  that  defines  the  possible  Diana  values 


VAL_CLASS  ::  = 


no_valua  => 
string  vt'  ia  => 
bool_vah»ft,  => 
irrt_valua  => 
real  value  => 


no_valua  I  strlng_valua  I  bool_valua  I 
int~valua  I  raal_valua; 

—  no  value  has  bean  computed 
str_val  :  String;  —  character  and  string 

boo_val  :  Boolean;  —  boolean  value 

intjval  :  Integer;  —  integer  value 

rtn_vat  :  Rational;  —  real  and  fixed  values 
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CHAPTER  3 
RATIONALE 


The  design  of  Diana  is  based  on  the  principles  listed  In  Section  1.1.  Unfor¬ 
tunately  these  principles  are  not  always  compatible  with  each  other  and  with  ADA. 
Under  some  circumstances  It  was  necessary  to  deviate  from  them,  albeit  In 
minor  ways.  The  main  purpose  of  this  chapter  is  to  clarify  the  Diana  approach 
and  to  give  reasons  for  our  compromise  decisions. 

An  important  principle  In  the  design  of  Diana  was  to  adhere  to  the  Formal 
Definition  of  Ada  (AFD) .  and  in  particular,  to  the  abstract  syntax  defined  there. 
The  first  section  below  compares  Diana  trees  with  those  of  the  Abstract  Syntax 
and  shows  the  transformations  from  the  Diana  form  back  to  that  given  In  the 
AFD.  The  second  section  describes  the  effects  of  separate  compilation  on 
Diana.  The  third  section  discusses  the  Diana  approach  to  the  notion  of  a 
dictionary  or  symbol  table.  In  the  fourth  section  we  discuss  an  Important  output 
of  the  semantic  analyzer— the  type  information  about  objects .  We  point  out 
special  situations  and  solutions  which  may  not  be  obvious  from  the  definition 
given  In  the  last  chapter.  The  fifth  section  discusses  another  principle  that  It 
was  not  possible  to  apply  consistently— the  requirement  that  there  be  a  single 
definition  for  each  entity.  Here  the  language,  and  especially  Its  separate 
compilation  facility.  Impose  a  compromise  on  Diana.  The  sixth  and  seventh 
sections  discuss  the  special  problems  of  Instantiations  and  renaming.  The  eighth 
section  deals  with  Implementation  dependent  attribute  types  that  are  introduced  In 
Diana  In  order  to  avoid  constraining  an  Implementation.  The  ninth  section 
discusses  the  notions  of  equality  and  assignment  for  attributes.  A  summary  of 
the  non-structural  attributes  closes  the  chapter. 

This  chapter  contains  a  number  of  examples  where  the  structure  of  Diana 
trees  Is  given  In  a  graphical  manner  to  Illustrate  the  relations  between  attribute 
values  and  nodes.  To  emphasize  the  important  points,  we  show  only  those  parts 
of  the  structure  which  are  of  Interest  for  the  particular  example.  Thus,  a 
subtree  Is  sometimes  replaced  by  the  string  which  It  represents  or  by  ellipses  If 
it  is  not  Important.  If  attributes  are  attached  to  a  node,  then  the  kind  of  the 
node  and  the  attributes  of  Interest  are  enclosed  In  a  box.  It  Is  our  Intention 
that  these  figures  capture  only  the  essential  Information  for  the  purpose  at  hand 
and  hence  suppress  unnecessary  detail:  they  should  not  be  viewed  as  complete. 
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3.1.  Comparison  with  the  Abstract  Syntax  Tree 

In  this  section  we  show  that  the  Abstract  Syntax  Trees  used  in  the  AFD  (8) 
and  the  Oiana  trees  (with  only  structural  attributes)  are  equivalent.  This  equiv¬ 
alence  Is  useful  for  the  description  of  the  semantics  of  a  Diana  tree:  we  simply 
Inherit  the  semantics  from  the  AFD.  Further.  It  enforces  standardization  of  the 
abstract  syntax  representation  of  programs.  Since,  however.  It  was  necessary  to 
deviate  from  the  AFD  In  minor  ways,  we  list  these  deviations  and  point  out  the 
reasons  why  they  are  necessary:  we  also  Indicate  how  the  Abstract  Syntax 
Tree  can  be  reconstructed  from  the  Diana  tree. 

We  recognize  that  the  Ada  AFD  Is  based  on  the  1980  revised  Ada  Language 
Reference  Manual  (71  and  does  not  reflect  changes  made  to  the  syntax  in  the 
1982  reference  manual.  This  issue  Is  addressed  in  Section  3.1.5. 

3.1.1.  Semantic  Distinctions  of  Constructs 

Several  nodes  in  Diana  have  no  counterpart  In  the  Abstract  Syntax  of  the 
AFD.  They  are  introduced  In  cases  where  a  single  construct  in  the  AFD  may 

have  several  distinct  semantic  meanings.  Different  nodes  allow  us  to  attach 

appropriate  semantic  attributes  to  each.  In  all  such  cases  the  name  of  the 
original  construct  is  extended  with  prefixes  which  denote  the  distinction.  The 
largest  number  of  splits  has  been  made  for  the  id-construct:  we  not  only 

distinguish  between  a  defining  occurrence  and  a  used  occurrence  of  an  iden¬ 

tifier.  but  also  between  the  kinds  of  the  Items  denoted  by  it.  For  example, 

const_ld  Is  a  node  which  can  appear  In  a  constant  declaration  to 

define  a  constant  object.  If  such  an  object  is  referenced 
by  an  Identifier  In  an  expression,  the  construct 

used_obiecl_id  is  used.  The  semantic  attributes  of  both  constructs  can  be 
found  In  the  Diana  definition. 

Note  that  the  attributes  of  these  two  types  of  *_id'  nodes  are  disjoint  and  that 
their  union  contains  ail  the  Information  needed. 

The  original  Abstract  Syntax  Tree  can  easily  be  reconstructed  by  omitting  the 
prefix  of  these  nodes.  it  should  be  noted  that  no  tree  transformation  is 
necessary,  since  the  structure  of  the  new  Diana  nodes  Is  the  same  as  that  of 
their  counterparts  in  the  Abstract  Syntax. 
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3. 1.2.  Additional  Concepts 

There  are  nodes  Introduced  In  Diana  which  are  used  to  deal  with  Issues  that 
are  not  considered  In  the  AFD.  They  are  used  to  represent  pragmas  and 
parentheses  In  expressions.  If  the  nodes  for  parentheses  and  pragmas  are 

removed  from  the  tree,  the  original  Abstract  Syntax  structure  is  restored. 

Under  some  circumstances  parentheses  have  a  semantic  effect  In  ADA.  Con¬ 
sider  the  following  examples: 

P(  (A)  )  —  Parameter  cannot  be  in  or  in  out 

A  +  (B  +  C)  —  Parentheses  force  the  grouping 

(A  +  8)  *  C  —  Parentheses  force  the  proper  parse 

In  each  of  these  cases  the  parentheses  have  a  semantic  effect.  In  addition,  the 

Ada  conformance  rules  (see  Section  6.3.1  of  the  Ada  LRM  (8)>  require  that 

parentheses  be  preserved  In  order  to  check  that  subprogram  specifications 

match.  Diana  requires  that  all  parentheses  In  the  original  Ada  source  are 

preserved  through  the  use  of  parenthesized  nodes.  See  Section  1.1.3. 

Pragmas  may  carry  the  commands  given  by  the  user  to  other  compiler 
modules  after  semantic  analysis  and  must  be  preserved.  Since  pragmas  may 
occur  In  so  many  places  In  ADA  (see  Section  2.8  of  the  Ada  LRM  181).  many 
Diana  classes  were  expanded  to  allow  pragmas.  This  does  not  affect  the 
structure  of  the  abstract  syntax  tree.  However,  the  presence  of  pragmas  also 
caused  us  to  change  the  structure  of  the  comp.unlt  node  of  the  abstract  syntax. 
Pragmas  can  be  given  for  a  compilation  unit  and  are  therefore  represented 

together  with  the  corresponding  node.  The  comp.unit  node  now  has  throe 
children: 

comp  unit  =>  context  :  CONTEXT, 

unit_txxiy  :  UNIT_BOOY, 

prtpm«_«  :  PRAQMA_S  ; 

From  the  abstract  datatype  viewpoint.  Diana  has  merely  added  one  additional 
selector.  The  original  selectors  of  the  AFD  are  retained  unchanged. 

3. 1 . 3.  Tree  Normalizations 

The  AFD  uses  various  normalizations  of  the  tree.  Most,  but  not  all.  of  them 
are  also  Imposed  by  Diana.  Those  which  are  not  performed  In  Diana  were  elided 
because  after  such  normalizations  It  Is  difficult,  and  sometimes  Impossible,  to 
reconstruct  the  source  text. 

We  do  not  follow  the  AFD  in  normalizing  anonymous  types.  The 
AFO  proposes  that  all  anonymous  types  be  replaced  by  type  marks  and  have  an 
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explicit  declaration  |uat  before  their  original  appearance.  This  tree  transformation 
Is  not  required  by  Diana.  For  example,  the  declaration  of  a  task  object  does  not 
require  a  declaration  of  an  anonymous  task  type  to  be  placed  In  the  Diana  tree 
before  the  task  object. 

We  do  not  normalize  parameter  associations.  In  the  AFD.  all  subprogram 
calls  have  their  parameter  sequences  normalized  to  the  named  association  form. 
Diana  leaves  positional  parameters  as  the  user  wrote  them  and  avoids  filling  In 
default  parameters.  (Diana  does  have  a  semantic  attribute  for  subprogram  calls 
that  normalizes  parameter  sequences  and  fills  in  default  parameters,  but  semantic 
attributes  are  not  represented  in  the  Abstract  Syntax  Tree) . 

All  other  normalizations  in  the  AFD  (e.g. .  treating  bullt-ln  operators  as 
function  calls)  are  Imposed  by  Diana.  The  Impact  of  these  normalizations  on 
reconstruction  of  the  original  source  program  from  the  Diana  tree  Is  discussed  in 
Appendix  III.  The  normalizations  which  are  not  assumed  by  Diana  must  be  done 
to  get  the  Abstract  Syntax  Tree;  the  AFD  defines  how  these  are  done. 

3.1.4.  Tree  Transformation  According  to  the  Formal  Definition 

Some  ambiguities  of  the  concrete  syntax  cannot  be  resolver*  by  the  parser, 
but  must  be  removed  during  semantic  analysis.  For  example,  the  Abstract 
Syntax  contains  an  apply  construct,  covering  indexed  expressions,  calls,  conver¬ 
sions.  and  slices.  In  most  cases  semantic  analysis  merely  has  to  rename  the 
node  to  encode  the  nature  of  the  construct;  there  are  no  structural  differences. 
The  result  of  this  process  is  assumed  in  Oiana  as  well  as  In  the  AFD  (See 
Appendix  It) .  It  should  be  noted  that  one  possibility  requires  a  structural 
transformation  of  the  tree,  namely  when  an  apply  node  has  to  be  changed  Into  a 
call  to  a  parameterless  entry  family  member.  Figure  3-1  illustrates  this  case. 
All  these  changes  are  In  accordance  with  the  AFD  and  require  no  actions  to 
reconstruct  the  Abstract  Syntax  Tree. 

3. 1 . 5.  Changes  to  the  AST 

The  majority  of  the  changes  In  ADA  syntax  have  not  produced  a  change  In  the 
structure  of  the  Abstract  Syntax  Tree.  For  example,  the  change  In  syntax  that 
requires  the  result  subtype  of  a  function  to  be  specified  by  a  type  mark  instead 
of  a  subtype  Indication  has  allowed  Diana  to  use  a  NAME  as  a  child  of  the 
function  instead  of  a  CONSTRAINED  node.  This  does  not  affect  the  structure  In 
the  sense  that  the  number  of  children  that  the  function  node  has  has  not 
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apply 


«ntry_call 


Int  number  used_name_id 


exp_s 


1nt_number 

Figure  3-1:  Example  of  a  Necessary  Tree  Transformation 

changed.  One  node  has  been  changed  structurally,  the  allocator  node,  which 
has  been  changed  to  have  only  one  child.  aa_exp_conatralned.  instead  of  the 
two  children  specified  in  the  Abstract  Syntax  Tree  defined  in  the  AFD. 

Two  Diana  nodes  have  been  Introduced  to  consistently  represent  the  changes 
to  Ada  syntax.  The  discriminant  specification  requires  a  type  mark  Instead  of  a 
subtype  Indication.  The  Abstract  Syntax  Tree  uses  a  var  node  to  represent  both 
discriminant  specifications  and  variable  declarations.  Diana  uses  a  separate 
node.  dscrmt_var.  to  represent  the  discriminant  specification.  Similarly,  a 
deferred  constant  declaration  differs  from  a  full  constant  declaration  In  that  It 
requires  a  type  mark  Instead  of  a  subtype  Indication.  Both  are  represented  by  a 
constant  node  In  the  Abstract  Syntax  Tree.  Diana  represents  the  deferred 
constant  declaration  with  the  deferred_constant  node. 

3.2.  Consequences  of  Separate  Compilation 

The  separate  compilation  facility  of  Ada  affects  the  Intermediate  representation 
of  programs.  The  Front  End  must  be  able  to  use  the  Intermediate  represen¬ 
tation  of  a  previously  compiled  unit  again.  Further,  the  Front  End  may  not  have 
complete  Information  about  a  program  unit. 

The  design  of  Diana  carefully  avoids  constraints  on  a  separate 

compilation  system,  aside  from  those  Implied  directly  by  the  Ada  language.  The 
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design  can  ba  extended  to  covar  tha  full  APSE  raqulramants.  Wa  hava  takan 
spaclal  cara  that  savaral  varsions  of  a  unit  body  can  axlst  corraaponding  to  a 
single  specification,  that  simultaneous  compilation  within  the  same  protect  Is 
possible,  and  that  units  of  other  libraries  can  ba  used  effectively  [5]. 

Tha  basic  decision  which  makes  these  facilities  tmplementable  is  to  forbid 
forward  references:  this  decision  Is  explained  In  the  next  section.  We  then  point 
out  some  limitations  Imposed  on  the  Front  End  by  the  separate 
compilation  facility. 

3.2.1.  Forward  References 

The  basic  principle  of  Diana  that  there  Is  a  single  definition  point  for  each 
Ada  entity  conflicts  with  those  Ada  facilities  that  have  more  than  one  declaration 
point.  In  these  cases.  Diana  restricts  the  attribute  values  of  all  the  defining 
occurrences  to  be  identical  (see  Section  3.5).  in  the  presence  of  separate 
compilation,  the  requirement  that  the  values  of  the  attributes  at  all  defining 
occurrences  are  the  same  can  only  be  met  temporarily.  The  forward  references 
lamjjody)  assumed  by  Diana  are  void  In  these  cases.  The  reasons  for  this 
approach  are: 

•  A  unit  can  be  used  even  when  the  corresponding  body  is  not  yet 
compiled.  In  this  case,  the  forward  reference  must  have  the  value 
void  since  the  entity  does  not  exist. 

•  Updating  a  Diana  representation  would  require  write  access  to  a  file 
which  may  cause  synchronization  problems  (see  [51). 

•  A  library  system  may  allow  for  several  versions  of  bodies  for  the  same 
specification.  If  we  were  to  update  an  attribute,  we  would  overwrite 
Its  previous  value.  Moreover,  we  believe  that  the  maintenance  of 
different  versions  should  be  part  of  the  library  system  and  should  not 
Influence  the  Intermediate  representation. 

3.2.2.  Separately  Compiled  Generic  Bodies 

The  Aoa  separate  compilation  facility  does  not  impose  a  total  order  on 
compilations.  It  Is  possible  to  use  a  unit  whose  body  has  not  yet  boen 
compiled,  provided  that  Its  specification  has  been  compiled.  This  procedure 
does  not  normally  cause  a  problem,  since  the  specification  usually  contains  all 
the  Information  needed  to  use  a  unit. 


However,  a  generic  unit  can  be  Instantiated  regardless  of  whether  the  generic 
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body  has  been  compiled.  Thus.  In  many  cases  the  Front  End  cannot  instantiate 
the  body  at  the  time  It  compiles  an  Instantiation.  It  would  be  possible  to  keep 
track  of  the  Instantiations  and  compile  them  once  the  body  becomes  available. 
But  this  method  would  imply  that  already-stored  Intermediate  representations  have 
to  be  modified.  After  such  an  update,  existing  references  to  the  updated  unit 
might  be  Invalid. 

Diana  assumes  that  only  the  specification  Is  Instantiated  (see  Section  3.6  for 
how  this  Is  done) .  This  assumption  is  safe,  since  the  specification  must  already 
have  been  analyzed.  The  task  of  Instantiating  the  body  Is  left  to  the  Back  End; 

the  Back  End  cannot  be  run  until  the  body  of  the  generic  unit  has  been 

analyzed.  This  procedure  has  the  advantage  of  allowing  the  Back  End  to  decide 
whether  to  use  common  code  for  several  Instantiations  of  the  same  generic  unit. 

3.3.  Name  Binding 

Each  entity  of  «*n  Ada  program  Is  Introduced  by  a  declaration  with  a  defining 
occurrence  of  the  name  of  that  entity.  Uses  of  the  entity  always  refer  back  to 
this  defining  occurrence.  Attributes  at  the  definition  point  make  it  possible  for 
ail  information  about  the  entity  to  be  determined.  The  defining  nodes  for  entities 
together  with  their  attributes  play  the  same  role  as  a  dictionary  or  symbol  table  in 
a  conventional  compiler  strategy.  To  support  the  Diana  approach,  the  appearan¬ 
ces  of  an  Identifier  In  the  tree  have  to  be  divided  into  defining  and  used 

occurrences  (see  Section  3.1.1). 

3.3.1.  Defining  Occurrences  of  Identifiers 

All  declarative  nodes  (see  DECL.  Section  2.3.1)  have  a  child  which  consists 
of  a  sequence  of  one  or  more  nodes  representing  the  identifiers  used  to  name 
the  newly  defined  entities.  These  nodes  are  termed  the  defining  occurrence  of 
their  respective  Identifiers:  they  carry  all  the  Information  that  describes  the 
associated  entity.  Because  the  set  of  attributes  which  Is  necessary  for  this 
purpose  depends  heavily  on  the  nature  of  the  denoted  entity,  we  distinguish  the 
defining  Identifiers  according  to  the  nature  of  the  entity  which  they  denote.  Thus 
we  have  the  following  set  of  node  types: 
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D€F_JO  vgumsntjd  1 

I 

oomp_M  I 
oo«*t_W  | 
4*crmt_td  | 
•ntry_H  l 
•oom_kJ  | 
•*e*pbon_W  I 
tur>cttoo_M  1 
gsnsrtc  td  | 
in_kl  I 
in_«ut_ld  I 
ltsr*bon_kt  I 
Isbstjd  | 
l_prtvsts_typOd  I 
n«m«d_*tm_ld  I 
number  M  I 


pragms_M  I 
pnvet*_typ*_W  I 
proc_td  | 
•ubtype_ld  I 
tMk_body_ld  I 
type_w  I 

v«r__jd; 


The  dellning  occurrence  of  an  enumeration  character  (DEF_CHAR)  and  of  an 
operator  (OEF_OP)  fall  Into  the  class  of  defining  occurrences  as  well. 


The  consistency  of  the  whole  scheme  requires  that  we  provide  a  definition 
point  for  predefined  Identifiers  as  well.  These  are  pragma  names  ( pragiMLJd) . 
attribute  names  <  attr_ld) .  and  the  names  of  the  arguments  of  pragmas 
( argument_ld> .  The  predefined  Identifiers  are  described  In  Appendix  I. 


It  should  be  noted  that  although  label  names,  loop  names,  and  block  names 
in  Aoa  are  Implicitly  declared  at  the  end  of  the  corresponding  declarative  part, 
they  are  not  explicitly  represented  In  Diana.  The  defining  occurrence  of  a  label 
(labeLJd)  is  its  appearance  in  a  labeled  statement.  The  defining  occurrence  of 
a  named_stm_ld  Is  Its  appearance  In  a  named  statement. 


3.  3.  2.  Used  Occurrences  of  Identifiers 


All  occurrences  of  Identifiers  which  are  not  mentioned  In  Section  3.3.1  are 
treated  as  used  occurrences.  The  node  for  a  used  occurrence  of  an  entity  has 
an  attribute  <«m_de/n  or  sm_op«rator)  that  refers  to  the  node  for  the  defining 
occurrence  of  that  Identifier  (where  all  Information  Is  stored).  Diana  distin¬ 
guishes  between  three  different  kinds  of  usage  depending  on  the  context  In  which 
the  entity  is  referenced. 

US6D_I0  : :  *  UMd_n«m«_M  I 

u*sd_ob)*ct_M  I 
uasd_Mtn_M; 
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A  ueed_obi*ct_id  Is  used  when  the  am_dafn  denotes  an  ob|ect.  an  enumera¬ 
tion  literal,  or  a  number.  In  all  other  contexts,  the  use  of  an  entity  is 
represented  by  a  used.namejd.  whose  only  attribute  refers  to  the  definition  of 
the  entity.  Additionally  we  have  a  used.char  (treated  as  a  us*d_ob|*ctJd)  and 
a  used_op  (treated  as  a  used_name_ld) .  Identifiers  for  built-in  entitles  are 
discussed  In  Section  3.  3.  4. 

3.3.3.  Multiple  Oefining  Occurrences  of  Identifiers 

Recall  that  one  of  the  basic  principles  of  the  Diana  design  stated  that  every 
entity  has  a  single  defining  occurrence.  As  this  Is  not  the  case  In  Ada  itself 
(e.g. .  incomplete  types,  deferred  constants).  Diana  cannot  strictly  follow  this 
principle.  In  the  Instances  where  multiple  defining  occurrences  can  occur.  Diana 
uses  the  following  solution.  Ail  defining  occurrences  of  an  entity  that  could  be 
multiply  defined  are  represented  by  a  DEF_ID  as  described  above  In  Section 
3.3.1.  However,  these  defining  occurrences  have  an  attribute,  am^firat.  that 
refers  to  the  node  for  the  flrat  defining  occurrence  of  the  Identifier,  similar  to 
the  am_d«fn  attribute  of  used  occurrences  (Section  3.3.2).  Nonetheless,  the 
several  defining  occurrences  of  the  entity  all  have  the  same  attribute  values. 
The  complete  details  of  how  Diana  treats  multiply  defined  identifiers  are  described 
in  Section  3.  5. 

3.3.4.  Subprogram  Calls 

In  Ada  It  is  possible  to  write  built— In  operators  as  function  calls  and  to  write 
user-defined  operators  as  operators.  For  example, 
afcandaxd. "V( x  »>  a,  y  »>  2) 

In  Diana  ail  function  calls  and  operators  are  represented  as  function  calls.  The 
only  exceptions  to  this  method  are  the  short-circuit  operators  and  then  and  or 
else  and  the  membership  operators  In  and  not  in.  which  cannot  be  overloaded, 
cannot  be  represented  as  functions,  and  cannot  be  written  as  function  cal>s. 

Diana  records  whether  a  function  call  was  made  using  Infix  or  prefix  notation 
through  the  fx_preffx  attribute.  This  Information  Is  necessary  for  subprogram 
specification  conformance  rules  (Section  6.3.1  of  the  ADA  LRM  (81). 

The  kind  of  function  call  Is  Indicated  by  the  first  child  of  the 
functlon.call  node,  which  represents  the  name  of  the  function.  This  attribute 
may  be  a  USED  JO  or  USED.OP.  or  a  selected  component  where  the 
DE8IGNATOR_CHAR  child  Is  a  USEDJD  or  USED_OP.  This  used  occurrence 


Pag*  88  /  Section  3.  3.  4 


Diana  Reference  Manual 


distinguishes  built-in  operators  (or  even  procedures  and  entries)  from  user- 
defined  subprograms. 

In  a  used.op  or  us*d_name_ld  node,  the  sm_detn  attribute  denotes  the 
defining  occurrence  of  the  user-defined  entity,  in  a  used_bltn_op  (or 
ue#d_bltn_ld) .  the  am_op9rator  attribute  indicates  the  built-in  entity:  this  attribute 
Is  a  private  type  and  is  Implementation-defined.  It  represents  numeric  operators 
such  as  *+*  and  **'.  but  also  represents  the  implicitly-defined  relations  for 
user-defined  types. 

Derived  subprograms  are  indicated  by  the  original  definition  from  which  they 
are  derived.  The  actual  parameters  ail  have  type  Information  attached.  It  is 
sufficient  to  compare  the  'actual  types  to  the  original  ones  to  determine  the 
Implicit  type  conversion  necessary  for  parameter  association  if  the  representation 
changes.  Since  type  checking  has  already  been  performed.  If  the 

am_exp_Jype  of  an  actual  parameter  Is  not  equal  to  the  am_oto/_fype  of  the 

corresponding  formal  (in  the  sense  described  In  Section  3.9).  it  must  be  the 
case  that  the  actual  parameter  Is  of  a  type  ultimately  derived  from  that  of  the 
formal.  Following  the  chain  of  derivations  starting  with  the  type  of  the  actual 
parameter  will  give  the  sequence  of  type  conversions  which  must  be  performed. 
Similarly  for  a  derived  function,  the  result  type  of  the  functlon_call  node  can  be 
compared  with  the  result  type  of  th  *unctlon_ld. 

If  a  user  defines  an  equality  operator  for  a  limited  private  type,  then  in¬ 
equality  is  Introduced  Implicitly.  The  user-defined  equality  is  Identified  by  the 
am^jiatn  attribute  of  a  used.op  node.  In  the  case  of  Inequality,  there  is  no 
defining  occurrence.  The  tree  Is  therefore  transformed  to  a  standard  *not* 
operation  applied  to  the  user-defined  equality.  This  situation  Is  illustrated  in 

Figure  3-2. 

The  parameter  associations  for  a  subprogram  call  are  In  the  user-written 

order:  it  Is  therefore  possible  to  reconstruct  the  source  program  in  most  cases. 
It  would  be  awkward  to  introduce  named  associations  in  the  case  of  predefined 
operators.  It  would  be  impossible  for  implicit  ones  such  as  equality,  since  there 
Is  no  defining  occurrence  of  the  formal  parameters.  Therefore.  Diana  does  not 
normalize  parameter  associations  to  named  associations.  However,  Diana  does 
us*  the  sm_normaHz9d_param_a  attribute  to  record  the  normalized  positional  list 
of  actuals  used  In  the  subprogram  call.  Including  any  default  actual  parameters. 
(The  attribute  sm_/»orma//z*d_comp_s  serves  a  similar  purpose  for  record 
aggregates  and  discriminant  constraints) . 
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function  call 


Figure  3-2:  Call  of  Implicitly-Defined  Inequality 


3.4.  Treatment  of  Types 

Since  anonymous  types  do  not  have  an  explicit  declaration  In  Diana  (see 
3.1.3).  we  cannot  use  the  type  identifier  as  the  description  of  the  type. 
Instead  we  use  the  type  specification  (TYPE_SPEC).  In  all  contexts  whore 
structural  type  Information  is  required,  the  attributes  have  values  which  denote  a 
TYPE_SPEC.  e.g. .  sm_exp_fype  in'  expressions  and  sm_ba3e_Jtyp9  in 
constrained  nodes.  This  treatment  Implies  that  all  nodes  which  can  represent  a 
type  specification  must  carry  those  attributes  which  describe  the  detailed  type. 
The  meaning  of  these  attributes  Is  explained  in  the  following  sections. 

It  should  be  noted  that  most  of  the  attributes  described  In  these  sections  can 
be  computed  from  other  attributes  which  are  also  present  In  Diana.  The  main 
reason  for  adding  them  Is  that  It  makes  code  generation  easier.  The  attributes 
represent  Information  which  the  Front  End  already  has  and  which  would  be 
difficult  for  the  code  generator  to  recompute  (especially  In  the  presence  of 
separate  compilation) . 
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3. 4. 1 .  Machlna  Depandant  Attrlbutas 

Diana  originally  required  machlna  dapandant  attrlbutas  to  ba  computed  because 
thalr  valuas  were  allowed  In  Ada  static  expressions  and  tharafora  could  appear  In 
type  declarations.  The  rules  for  static  axprasaiona  (Sactlon  4.9  of  the  Ada 
LRM  (81)  now  only  allow  attrlbutas  of  static  subtypes  in  static  expressions:  at¬ 
trlbutas  whose  valuas  are  no  longer  machlna  dapandant. 

3.4.2.  Type  Specifications 

Thera  are  several  ways  to  specify  a  type  In  Ada.  Fortunately  they  all  have 
different  syntactic  structures  so  that  wa  are  not  forced  to  introduce  new  node 
types  to  carry  the  different  semantic  attributes  appropriate  to  each  type  (as  was 
dona  for  identifiers,  see  3.1.1).  The  following  sections  give  a  detailed  descrip¬ 
tion  of  the  attributes  for  each  kind  of  type  specification.  These  descriptions 
involve  the  notion  of  structural  type  Information:  this  notion  is  defined  In  the 
following  section. 

3. 4.2. 1.  Structural  Type  Information 

The  structural  Information  for  a  typo  la  expressed  by  the  following  nodes  of  a 
Diana  Tree: 

integer,  fixed,  float  for  numeric  types 

enumJLiteraX.s  for  enumeration  types 

rsoord  for  record  types 

ax  ref  for  array  types 

taakjapeo  for  task  typos 

and  the  universal  types  (see  Appendix  I).  Each  of  these  has  attributes  for 
values  of  user  defined  or  Implementation  chosen  attributes. 

There  are  language  pragmas  (PACK,  CONTROLLED)  which  can  be  applied  to 
types  and  which  are  used  Instead  of  a  representation  specification.  Occurrences 
of  these  pragmas  remain  In  the  Diana  Tree  to  reconstruct  the  source,  but  they 
are  additionally  recorded  with  the  type  structures  they  affect  using  the 
am_packlng  and  am^oontrolled  attributes. 

For  record  types,  there  may  be  representation  specifications  for  the  record 
and  Its  components  (Including  discriminants).  A  reference  to  this  specification 
Is  recorded  In  semantic  attributes  of  the  record_kf,  oomp_id.  and 
dsormt_ld  nodes.  Similarly  for  enumeration  types.  Information  from  represen¬ 
tation  specifications  for  the  enumeration  literals  is  recorded  with  the  enum_id. 
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3. 4. 2. 2.  8ubtyp*  Specifications 

All  subtypa  Indications  are  represented  by  a  constrained  nod*  which  has  type 
mark  and  constraint  attributes.  The  constraint  can  be  void.  A  subtype 
declaration  can  also  be  used  Just  to  rename  a  type  (when  no  constraint  is 
given) .  so  there  may  be  a  sequence  of  subtype  declarations  without  constraint 
Information.  For  code  generation  purposes.  It  is  necessary  to  know  the  last 
applicable  constraint,  hence  a  constrained  node  In  Diana  has  a  corresponding 
attribute,  am  constraint,  that  points  directly  to  this  constraint;  the  code  generator 
Is  not  forced  to  walk  backwards  through  the  chain  of  subtype  declarations  to  find 
the  appropriate  constraint. 

For  fixed  and  floating  point  types  the  last  applicable  constraint  may  have  two 

parts,  a  digits  (or  delta)  constraint  and  a  rang*.  In  order  for  the  am  constraint 

to  point  to  the  last  applicable  constraint,  a  fixed  or  float  node  may  need  to  be 

created  for  the  purpose  of  representing  this  constraint.  For  source 

reproducibility  reasons,  the  structural  constraint  may  not  contain  all  of  the 

relevant  Information.  Figure  3-3  Illustrates  the  float  node  that  Diana  creates  for 

the  following  example: 

type  MYFUJAT  is  digits  6  range  -1.0. .1.0, 
subtype  NXFLQKT2  is  nxnoaae  digits  2; 

The  code  generator  also  needs  the  Information  about  the  type  structure, 
which  Is  obtained  from  the  original  type  from  which  all  Intermediate  derived  types 
and  subtypes  are  constructed.  This  attribute  Is  named  amjppactruct.  Note 
that  for  derived  record  and  enumeration  types  It  denotes  the  duplicated  type 
structure.  If  any.  This  situation  Is  discussed  in  the  next  section.  3.4. 2.3. 

In  a  chain  of  type  specifications,  a  user  can  add  attributes  to  each  type  by 
representation  specifications;  these  specifications  are  possible  only  for  types,  not 
for  subtypes.  The  type  from  which  a  subtype  is  constructed  Is  called  Its  base 
type.  The  attribute  amCaaa_Jyp*  denotes  Its  type  specification.  /.*. .  a  derived 
type  (see  Section  3. 4. 2.3)  or  a  type  structure  (see  8*ction  3. 4. 2.1)  where  all 
representation  information  can  be  found.  The  Diana  structure  that  results  In  such 
a  case  Is  illustrated  for  the  following  example  In  Figure  3-4.  Note  that  all 
information  Is  present  at  the  last  subtype  declaration:  it  Is  an  Integer  type,  the 
values  are  in  the  range  1..9.  and  Its  representation  must  not  exceed  8  Bits. 
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type 


“MYFLOAT" 


float 


subtypo 


^  float 


•2"  range 

/\ 

••1.0"  "1.0" 


"2"  void 


Figure  9-8:  Float  oonatratnt 
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type  Ti  la  rang*  l.  .iooo; 
subtype  «  is  Tl  rang*  i.  .9; 
typ*  T3  is  MW  T2» 
subtype  T*  is  T3> 

•lAtjft  T5  is  T4> 

•  a  • 

Cor  TS'SIZE  us*  8| 


3. 4.2.3.  D*rlv*d  Types 

A  d*rtv*d  type  is  us*d  to  introduce  a  new  typ*  which  Inherits  characteristics 
ot  the  parent  type.  A  user  can  give  a  new  representation  specification  for  every 
derived  typ*.  If  no  representation  Is  specified,  then  the  attributes  of  the  parent 
type  are  Inherited.  To  treat  all  derived  types  uniformly,  the  corresponding  Diana 
attributes  are  copied  and  stored  with  the  derived  type  specification.  The  values 
are  overwritten  If  the  user  gives  a  new  representation.  To  support  this,  the 
attributes  am^pU *.  am_ptoraga_jal2a .  am_actual_dalta .  am_packlng .  and 
am^jsontrollad .  as  well  as  cd_Jmpt_atz».  are  present  in  a  derived  node. 

The  subtype  Indication  defines  the  parant  aubtypa  and  the  parent  type  Is  the 
base  type  of  the  parent  subtype  (ADA  LRM  [81.  Section  3.4).  so  the  information 
about  the  parent  type  can  be  obtained  from  the  subtree  of  the  derived  node. 
The  corresponding  subtype  Indication  is  represented  by  a  constrained  node  which 
has  an  attribute  amjfaaajypa  (which  denotes  the  base  type)  and  an  attribute 
am_Jypa_jttruct  (which  denotes  the  structural  Information  for  that  type) ;  see 
Section  3.4. 2.2. 

If  this  structure  Is  a  record  or  an  enumeration  type,  then  it  is  possible  that  a 
representation  specification  Is  given  for  the  derived  structure— overwriting  the  old 
values.  For  a  record  structure,  these  values  are  recorded  with  the  component 
declarations  (e.g. .  eomp.td  has  the  attribute  am_comp_apvc) .  in  the  case  of 
an  enumeration  type,  the  values  are  recorded  with  the  enumeration 
literal  (*num_ld  has  an  attribute  sm_r#p) .  The  solution  of  this  problem  In  Oiana 
requires  the  creation  of  a  new  type  structure  where  the  new  attribute  values  can 
be  filled  in.  This  new  structure  Is  referenced  by  the  amjypajttmot  attribute  of 
the  constrained  node  of  the  derived  typ*  declaration. 

Duplication  has  another  advantage  for  enumeration  literals;  since  we  now  have 
a  defining  occurrence  lor  a  literal,  the  derivation  of  an  enumeration 
type  Introduces  new  defining  occurrences  for  literals  that  belong  to  the  derived 
type  and  overload  the  old  ones. 
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type  subtype 


•U*  'SIZE* 


Figure  9-4 :  Due*  Form  o*  type/euMype  SpocMootton 
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Th*  duplication  of  tho  record  structure  it  only  meaningful  and  necessary  If  a 
representation  specification  is  given  by  the  user.  An  implementation  of  Diana 
can  choose  whether  to  copy  or  to  denote  the  old  struoture.  It  makes  no 
difference  from  the  logical  point  of  view. 

In  figure  3-5  we  Illustrate  the  Oiana  structure  that  results  from  the  following 
Ada  source. 

type  T1  la  (BED,  GREEN); 
type  T2  Is  new  Tl; 
for  T2  use  (5,  iO)t 

type 


/\ 


Figure  3-5:  An  Example  for  Derived  Enumeration  Types 
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3.4. 2. 4.  Incomplete  and  Private  Types 

For  incomplete  and  private  types,  there  are  two  defining  occurrences  of  the 
same  entity.  The  general  solution  for  entitles  with  several  declaration  points  Is 
discussed  In  Section  3.  S;  the  approach  for  Incomplete  and  private  types  In 
particular  is  described  In  Section  3.5.1. 

3. 4. 2.  5.  Anonymous  Array  Types 

The  Ada  rules  for  multiple  elaborations  (Ada  LRM  [6]  Section  3.3.1)  require 
that  the  ob|ect  declaration: 

X,  Yt  array  (1..10)  of  INTEGER  i-  (1..10  ->  0) 
result  in  X  and  Y  having  different  types  and  In  fact  also  cause  the 
aggregate  occurring  above  to  be  evaluated  twice  with  two  different  types  In  the 
two  evaluations.  Oiana  requires  that  the  var.ld's  for  X  and  Y  refer  to  different 
intermediate  nodes  so  that  the  fact  x  and  Y  are  different  types  can  be  readily 
determined. 

3. 4.  2.  6.  Anonymous  Derived  Types 

The  Ada  semantics  require  that  an  Integer  type  declaration  is  equivalent  to  a 
subtype  declaration  of  an  anonymously  derived  Integer  type  (Section  3.  5.  5  of  the 
Ada  LRM  (81).  To  represent  this  In  Oiana  without  normalizing  the  source  program 
we  have  Introduced  the  attribute  sm_fias9_fypm  for  Integer  nodes  that  denotes  a 
derived  node  that  Is  created  to  give  a  unique  type  definition  for  the  subtype. 
Similarly,  this  attribute  is  also  present  on  float  and  fixed  nodes. 

3.4.3.  Type  Specifications  in  Expressions 

Diana  records  the  result  of  overload  resolution  in  every  expression  node:  the 
am_mxp_Jyp*  attribute  denotes  the  result  type  of  the  expression.  Additionally,  if 
the  value  Is  statically  evaluated,  the  value  Is  recorded  In  the  am_valum  attribute 
(see  Section  3.8.1). 

As  far  as  overloading  resolution  is  concerned,  only  the  base  type  of  an 
expression  Is  of  Interest.  However,  for  expressions  which  denote  values  which 
are  assured  to  satisfy  a  certain  constraint,  the  constraint  Information  is  useful. 
For  this  reason  am_sxp_fype  should  refer  to  a  constrained  node  for  (only)  the 
following  nodes: 

•  conversion  and  qualified  whose  as_name  denotes  a  subtype  name. 

•  Indexed  and  all. 
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•  funetlon_eall.  If  th*  function  name  Is  not  a  built-in  operator,  and 

•  us*d_obJ*ct_ld  If  th*  object  Is  not  d*ctar*d  using  an  array  typ* 
specification  and  Is  not  a  single  task. 

Th*r*  ar*  three  kinds  of  expressions  which  Implicitly  Introduce  an  anonymous 
subtype:  aggregates,  slices,  and  string  literals.  The  resulting  subtype  can  be 
used  to  constrain  an  object  if  such  an  expression  appears  as  an  Initial  value  for 
a  constant  object  of  an  unconstrained  array  type  (Ada  LRM  [81.  Section  3.8.1). 
The  sm_conatralnt  attribute  Is  used  in  these  cases  to  denote  a  corresponding 
subtype  constraint.  Unfortunately,  this  constraint  does  not  exist  In  all  cases,  so 
it  must  be  computed  by  creating  a  suitable  structure  outside  the  tree. 

In  the  case  of  a  record  aggregate  the  discriminant  values  are  extracted  from 
the  aggregate  and  used  to  build  a  dscrmt_aggregat*  node  as  a  constraint  for  the 
type  to  which  the  aggregate  belongs. 

In  the  case  of  an  array  aggregate  the  constraint  attribute  denotes  a  range 
whose  bounds  are  computed  as  described  In  the  Ada  LRM  [8],  Section  4.3.2. 
This  rang*  can  be  used  as  a  constraint  for  the  index  type  of  the  underlying 
array  structure. 

The  am_ponatralnt  attribute  of  a  string  literal  denotes  a  range  whose  bounds 
are  computed  from  the  underlying  string  type  (denoted  by  sm_9xp_jypa')  and  the 
length  of  the  string  literal. 

In  th*  preceding  two  cases,  the  constraint  must  be  constructed  outside  the 
tree,  in  the  case  of  slices,  it  is  already  present:  either  it  denotes  the  range  of 
the  slice  Itself  or.  If  only  a  type  mark  was  given,  it  denotes  the  range  of  the 
corresponding  subtype. 

Note  that  because  Diana  creates  structures  outside  of  the  tree,  an  obvious 
tree  traversal  (on*  that  reaches  only  the  structural,  'as_',  attributes)  will  not 
yield  all  of  th*  structural  information.  Tree  traversals  that  yield  all  of  th* 
structural  information  do  exist:  these  necessarily  follow  some  semantic  attributes 
as  well  as  th*  structural  attributes. 

3. 4.3.1.  Examples  for  Constraints  of  Expressions 

Figures  3-8  and  3-7  Illustrates  the  Oiana  structure  for  the  following  Ada 
source. 
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tipa  IX  ia  gauge  1, .1000; 
type  X  la  array  (XX)  of  integer; 
ettrtype  12  ia  ix  range  X.  .10; 

B  t  X; 

The  figures  provide  examples  for  the  value  of  the  am  ^constraint  attribute  for 
slices  and  aggregates. 

Figure  3-8  illustrates  the  Diana  structure  for  the  following  Ada  source. 

type  *k_3TRINg  ia  array  (INTEGER  range  <> )  of  CHARACTER; 
c  t  constant  my_string  »-  "ABC"; 

3. 4. 3. 2.  Type  Specifications  for  Names 

The  Diana  class  EXP  Includes  the  class  NAME  which  can  appear  In  contexts 
other  than  expressions  </.e. .  wherever  a  name  can  appear  In  an  Ada  program), 
in  ali  contexts  other  than  expressions,  there  is  no  type  and  no  value  which  can 
be  associated  with  the  nodes  representing  the  name.  However.  It  Is  not 

possible  to  attach  different  attributes  to  the  same  node  type  depending  on  the 
context  in  which  it  Is  used.  This  section  defines  the  values  of  these  attributes 
for  these  cases.  (It  should  be  noted  that  those  nodes  in  the  class  NAME  that 
can  never  represent  an  expression,  e.g. .  any  node  In  the  class  DEF_ID.  do  not 
have  the  attribute  am_yalue.  This  discussion  Is  limited  to  those  names  that  may 
be  used  to  represent  an  expression.) 

We  require  that  the  value  of  am_exp_jypo  be  void  for  name  nodes  which  are 
not  used  to  represent  expressions.  The  «m_va/ue  attribute  In  these  cases  must 
have  a  distinguished  value  (see  3.8.1)  which  indicates  that  the  attribute  has  not 
been  evaluated.  This  applies  as  well  to  used_char  when  it  appears  in  contexts 
other  than  expressions. 

Consider  the  following  two  Ada  fragments. 

B  «-  P.Q; 

X  I-  P.Q'XDORESS 

In  both  cases  P.Q  is  represented  by  a  selected  node.  In  the  first  case  It  Is 
used  in  an  expression.  A  type  can  be  attached  to  the  selected  node.  Indicating 
the  type  of  the  selected  object.  In  the  second  case  the  selected  node  Is  used 
to  denote  an  object  for  which  an  Ada  attribute  is  to  be  computed.  The  node 
might  have  a  type,  as  before,  but  this  type  Is  unnecessary  since  the  evaluation 
of  the  attribute  does  not  depend  on  It.  A  more  convincing  example  is  the 
appearance  of  a  selected  node  in  a  with  clause. 


Note  that  the  aeleoted  node  does  not  have  a  «m_va/ue  attribute  and  does  not 
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Example  1  :  Representation  of  b(l..S) 
(slice  with  range) 


type  v&r 


Figure  9-6: 


Constraints  on  BUoes  and  Aggregates 
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Example  3  :  Representation  of  b(12) 
(slice  with  subtype) 


/\ 


•1*  -10' 


Figure  9-7:  Constraints  on  Siloes  and  Aggregates 
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type 


/\ 


INTEGER'FIRST  INTEGER'FIRST+2 


Figure  3-8:  Constraints  on  String  Literals 
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record  its  value  In  the  context  of  an  expression.  Only  expressions  of  scalar 
types  can  be  static  (Aoa  LRM  (81  Section  4. 9) .  Thus  the  Diana  nodes  selected. 
Indexed,  slice,  all.  and  aggregate  do  not  have  the  attribute  am_value. 

3.5.  Entitles  with  Several  Declaration  Points 

One  of  the  basic  principles  of  Diana  requires  that  there  Is  a  single  definition 
of  each  Aoa  entity.  This  conflicts  with  those  Aoa  facilities  that  allow  or  require 
more  than  one  declaration  point  for  the  same  entity: 

•  incomplete  type  declarations 

•  (limited)  private  type  declarations 

•  deferred  constants 

•  subprogram  declaration  and  body 

•  package  declaration  and  body 

•  subprogram  formats  (In  the  formal  part  of  subprogram  declaration  and 
body) 

•  discriminants  (In  the  discriminant  part  of  incomplete  or  private  types) 


All  instances  of  multiple  defining  occurrences  are  treated  as  consistently  as 
possible.  The  principles  that  apply  In  all  cases  are 

1.  The  first  defining  occurrence  of  an  entity  Is  treated  as  tha  defining 
occurrence,  and 

2.  all  references  to  the  entity  should  reference  the  first  defining  occur¬ 
rence. 

All  defining  occurrences  are  represented  with  DEF_ID  nodes  (Section  3.3.3). 
Multiple  defining  occurrences  create  multiple  Instances  of  the  same  DEFJD 
node.  Diana  uses  the  attribute  sm_Jlrat  to  differentiate  among  defining  occur¬ 
rences  and  to  allow  references  back  to  the  first  defining  occurrence.  The 
attribute  am_flrst  references  the  first  defining  occurrence  of  the  entity  In  the 
same  way  antedate  denotes  the  defining  occurrence  for  a  ueed_!d.  The  node 
that  is  the  first  defining  occurrence  has  an  am  .first  that  references  Itself. 

Note  that  ail  used  occurrences  must  reference  the  same  defining  occurrence, 
the  one  that  occurs  first.  This  Is  the  most  consistent  approach  since  this  is  the 
occurrence  that  Is  elaborated  In  Ada  semantics.  This  requirement  allows  for  a 
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consistent  treatment  of  all  Identifiers.  The  attributes  for  all  defining  occurrences 
must  still  be  determined  and  for  all  defining  occurrences  the  attributes  must  be 
Identical.  (The  attributes  may  be  different  when  separate  compilation  Issues 
Intervene;  see  Section  3.2.1). 

There  Is  only  one  case  that  deviates  from  these  principles,  the  case  of 
(limited)  private  types.  Private  types  are  given  special  treatment  In  Diana,  as 
they  are  In  Ada  (Section  3.5. 1.2). 

In  the  following  paragraphs  we  show  the  details  of  the  Diana  structure  which 
preserves  these  principles.  We  present  the  details  Individually  for  all  the  cases 
where  the  language  allows  several  declaration  points  of  the  same  entity.  (It 
should  be  noted  that  representation  specifications  are  not  treated  as  declaration 
points,  although  they  do  appear  In  declarative  parts. ) 

3.5.1.  Type  Declarations 

There  are  two  forms  of  type  declaration  In  which  information  about  the  type  is 
given  at  two  different  places:  private  and  Incomplete  types. 

3. 5. 1.1.  Incomplete  Type  Declarations 

The  notion  of  an  Incomplete  type  permits  the  definition  of  mutually  dependent 
types.  Only  the  new  name  Is  Introduced  at  the  point  of  the  Incomplete  decla¬ 
ration.  The  structure  of  the  type  Is  given  in  a  second  type  declaration  which 
must  appear  In  the  same  declarative  part.  (This  restriction  ensures  that  there  Is 
no  Interference  from  separate  compilation.) 

The  defining  occurrences  of  both  types  are  described  by  type_ld  nodes  which 
have  the  semantic  attribute  an?_fype_?pec.  In  both  cases,  the  value  of  this 
attribute  can  denote  the  full  type  specification  which  satisfies  the  Diana  restric¬ 
tion.  The  defining  nodes  also  have  the  attribute  am_flrat  which  refers  to  the  first 
occurrence,  the  incomplete  declaration.  Note  that  If  the  incomplete  type  decla¬ 
ration  includes  a  discriminant  part,  that  becomes  the  defining  occurrence  of  the 
discriminant  Identifiers  (see  Section  3.  5. 1.3  below). 

Figure  3-9  Illustrates  the  Diana  structure  for  the  following  Incomplete  type 
declaration. 

typ*  T> 

e  •  • 

type  T  1a  record  . . .» 


t 
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type  •  •  .  type 


Figure  3-9:  Example  of  an  Incomplete  Type 

3.5.1. 2.  Private  Types 

Private  types  are  used  to  hide  Information  from  the  user  of  a  package:  a 
private  type  declaration  Is  given  In  the  visible  part  of  a  package  without  any 
structural  Information.  The  full  declaration  Is  given  In  the  private  part  of  the 
package  specification.  (This  restriction  ensures  that  there  Is  no  interference 
from  separate  compilation) .  Unfortunately,  we  cannot  adopt  the  solution  used 
for  Incomplete  types:  If  both  defining  occurrences  had  the  same  node  type  and 
attributes,  we  could  not  determine  whether  the  type  Is  a  private  one  or  not. 
This  information  Is  important  when  the  type  is  used  outside  of  the  package. 

Diana  views  the  declarations  as  though  they  were  declarations  of  different 
entities— one  is  a  private  type  and  the  other  a  normal  one.  Both  denote  the 
same  type  structure  In  their  am_fyp9_jspoc  attribute,  however.  The  distinction  Is 
achieved  by  Introducing  a  new  kind  of  a  defining  occurrence,  namely  the 
prtvate_type_td.  It  has  the  attribute  am_fype_spec  which  denotes  the  structural 
information  given  In  the  full  type  declaration.  Limited  private  types  are  treated  In 
the  same  way.  except  that  their  defining  occurrence  Is  a  l_prtvate_typ*_ld .  In 
the  case  of  (limited)  private  types  the  smjlrat  attribute  of  the  typ*_ld  node 
refers  to  the  prtvat*_type_id  or  l_prtv«te_type_ld. 

Figure  3-10  Illustrates  the  Diana  structure  for  the  following  example. 
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pgi*a.te 


Dzrjr  la 
T  la  private) 


typ* 


Figure  3-10:  Exampl*  of  a  Private  Type 

Sine*  w*  have  Introduced  two  distinct  defining  occurrences  for  the  private 
type  we  must  specify  which  of  these  definitions  a  used  occurrence  refers  to. 
Any  use  outside  of  the  package  denotes  the  prtvate_typ*_ld  or  l_prtvate_ld  (but 
nevertheless  has  structural  Information)  and  any  usage  Inside  the  package 
denotes  the  full  type  declaration:  In  the  interior  context,  there  are  no  restrictions 
on  the  use  of  the  type. 

3.5.1. 3.  Discriminant  Parts 

When  an  Incomplete  type  declaration  or  (limited)  private  type  declaration 
contains  a  discriminant  part,  the  discriminant  part  must  also  appear  In  the 
normal  type  declaration.  This  creates  a  multiple  definition  of  the  discriminant 
Identifiers.  Thus  the  dscrmOd  nod*  also  has  an  attribute  amjlrat  that  refers  to 
the  first  definition  point.  Aoa  semantics  demand  that  the  discriminant  part  be 
elaborated  at  the  first  occurrence. 

The  attribute  am^dlaerlmlnatfta  exists  for  l_prtvate  and  private  nodes  because 
for  a  generic  formal  private  type  declaration,  the  discriminants  are  not  supplied 
until  Instantiation.  After  instantiation,  this  attribute  denotes  the  discriminants 
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suppliad  by  the  ganarlo  actual  typa. 

Whan  a  discriminant  part  fa  supplied  In  tha  ( limited)  private  typa  declaration, 
tha  am.dfacrfmfnants  ot  tha  private  node  and  tha  record  node  In  tha  normal  typa 
declaration  should  always  refer  to  the  discriminants  In  the  first,  (limited)  private, 
typa  declaration. 

3.5.2.  Deferred  Constants 

Deferred  constants  are  a  direct  consequence  of  the  concept  of  private  types: 
since  the  structural  details  of  a  type  are  hidden,  the  structure  of  the  Initialization 

expression  must  be  hidden  as  well.  They  are  deferred  to  the  private  part.  The 

deferred  constant  declaration  (rspresented  by  the  node  deferred_constant)  and 
the  full  declaration  of  the  deferred  constant  (a  constant  node)  are  both  defining 
occurrence  of  the  constJd.  The  attributes  of  both  defining  occurrences  of  a 
deferred  constant  have  the  same  values,  satisfying  our  requirement.  The  at¬ 
tributes  denote  the  type  specification  and  the  Initialization  expression.  Both 

attribute  values  are  equal  to  those  of  the  full  declaration  of  the  deferred  con¬ 

stant.  Not*  that  const_ld  also  has  the  attribute  sm _flrat  to  denote  the  first 
defining  occurrence.  Figure  3-11  Illustrates  the  Diana  structure  for  the  following 
example. 

type  T  la  private* 

A  i  constant  Ti 

•  •  a 

type  T  la  range  0.  .10* 

A  *  constant  t  «-  o» 


3. 5. 3.  Subprograms 

The  declaration  and  body  of  a  subprogram  can  be  separate  from  each  other. 
Moreover,  in  the  case  In  which  the  body  I*  compiled  as  a  subunit,  a 
stub  declaration  can  also  be  given.  All  three  declarations  can  appear  In 
different  compilation  units:  the  declaration  In  a  package  specification,  the  stub  in 
the  package  body,  and  the  body  as  a  compilation  unit  (subunit)  Itself.  We  first 
examine  the  simplest  case  where  declaration  and  body  appear  In  the  same 
declarative  part.  Then  we  adapt  the  solution  for  the  cases  where  separate 
compilation  Is  Involved. 
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3. 5.3. 1.  Daclaratlon  and  Body  in  On*  Declarative  Part 

Th*  declaration  and  th*  body  of  a  subprogram  are  viewed  In  Diana  as 
belonging  to  th*  same  entity.  Therefor*,  according  to  our  restriction,  both 
defining  occurrences  must  reference  the  first  defining  occurrence  (the  sub¬ 
program  declaration)  and  must  have  th*  same  attribute  values.  Since  th*  header 
of  the  first  defining  occurrence  Is  used  to  elaborate  th*  subprogram,  th* 
«m_jip*c  attribute  of  both  defining  occurrences  denotes  th*  header  of  th*  decla¬ 
ration. 

Both  defining  subprogram  identifiers  further  reference  th*  blook  which 
describes  the  body.  This  method  leads  to  th*  structure  shown  in  Figure  3-12. 
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subprogram  .dad 


Flgura  3-12:  Subprogram  8tructura 

3. 5.3. 2.  Oaclaration  and  Body  in  Different  Compilation  Units 

Slnca  a  subprogram  body  cannot  appaar  In  a  packaga  specification  but  must 
be  declared  in  the  package  body,  and  since  package  bodies  will  often  be 
separately  compiled,  the  declaration  and  body  of  the  subprogram  will  often  be  In 
separate  compilation  units. 

Updates  to  previously  complied  units  are  forbidden  In  Diana.  Therefore,  it  Is 
not  possible  to  Insert  the  value  of  amjaody  In  the  declaration.  The  reasons  for 
this  decision  are  discussed  In  more  detail  In  Section  3. 2. 1 .  Therefore,  in  all 
cases  where  the  body  Is  In  a  separate  unit,  the  value  of  amjtxxty  Is  void. 
Nevertheless.  If  the  Oiana  tree  for  the  declaration  Is  processed,  the  attribute  may 
be  temporarily  set  to  point  to  the  corresponding  body  if  It  Is  present  as  well. 
Thus,  during  processing  Diana  principles  for  multiple  definitions  are  followed. 

The  permanent  structure  for  a  subprogram  declaration  and  body  In  separate 
compilation  units  is  as  shown  in  Figure  3-13. 
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subprogram  _dtcl 


Ftgura  3-13:  Subprogram  Oaclaration  and  Body  in  Different  Compilation  Unto 

3.5.3. 3.  Subprogram  Bodlaa  as  subunits 

It  a  subprogram  body  Is  compilad  as  a  subunit,  it  is  possible  for  there  to  be 
a  third  defining  occurrence,  a  stub  declaration,  making  a  defining  occurrence  in 
three  different  compilation  units.  We  adapt  the  solution  presented  above,  adding 
the  stub  declaration  which  makes  the  picture  more  complicated,  as  is  shown  In 
Figure  3-14. 

The  attribute  sm^jtub  is  used  to  refer  to  the  defining  occurrence  of  the  stub. 
This  attribute  provides  a  quick  means  of  finding  the  stub  when  it  Is  In  a  separate 
compilation  unit.  Figure  3-15  shows  the  Diana  values  for  the  attributes 
am^Jirat  and  am_atub .  (In  subsequent  figures  the  values  for  the  attributes 
am^JIrat  and  sm.jsft/6  are  not  shown.  The  treatment  of  am_Jlrat  and  3m_sfub  for 
other  OMMA  constructs  does  not  differ  significantly  from  the  treatment  shown  In 
figure  3-15. ) 

Just  as  am_body  is  prevented  from  forward  references,  the  value  of 
am^jtub  is  required  to  be  void  when  the  stub  appears  in  a  separate 
compilation  unit. 
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Flgura  3-14:  Exampla  of  a  Subprogram  Body  aa  a  subunit  (I) 

3.  5.3.4.  Entrlas  and  Accept  Statamants 

An  ontry  daclaratlon  and  Its  corraapondlng  accapt  statamants  ara  not  traatad 
as  dlffarant  daflnltlon  points  of  tha  sama  antfty.  Tha  abstract  syntax  Indloatas  a 
nama  for  an  accapt  statamant  which  is  vlawad  as  a  usad  occurranca;  Diana  usas 
tha  sama  approach.  Thus  tha  antry_ld  Is  tha  unlqua  defining  occurranca:  a 
used_name_ld  appears  as  a  child  of  an  accapt  statamant  and  rafars  to  tha  antry 
daclaratlon.  Howavar.  tha  formal  part  of  tha  antry  daclaratlon  and  tha  accapt 
statamant  multiply  daflna  tha  antry  formats  (saa  Sactlon  3.  5. 3.5  balow). 

3. 5. 3. 5.  Subprogram  Formats 

Whan  tha  daclaratlon  of  a  subprogram  is  separata  from  tha  subprogram 
body  (and  stub)  tha  subprogram  formal  part  is  rapaatad.  This  creates  a 
multiple  daflnltlon  of  tha  subprogram  formats.  Thus  tha  subprogram  defining 
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subprogram  _dec1 


Flgur*  3-15:  Exampl*  of  a  Subprogram  Body  as  a  subunit  (II) 

occurrences  (ln_ld.  ln_out_ld,  and  outJd)  hav*  th*  attribute  am_flrat  to  refer  to 
the  first  occurrence.  Ada  semantics  require  that  the  first  occurrence  Is  the  one 
that  Is  elaborated. 

This  treatment  applies  to  formal  parts  in  entry  declarations  at.d  accept  state¬ 
ments  also. 

3. 5. 4.  Packages 

Packages  are  declared  by  at  least  a  specification  and  possibly  a  body:  in  the 
case  of  subunits,  a  stub  declaration  must  also  be  given.  Thus  packages  present 
the  same  situation  as  subprograms,  and  the  Diana  treatment  of  packages  Is  In 
principle  die  same  as  that  for  subprograms  (except  that  the  structure  and  the 
attribute  names  ere  different). 
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Wa  raatrict  oursalves  to  tha  complicated  caaa  of  having  thraa  different  defini¬ 
tion  places  for  packages;  tha  Oiana  structure  Is  shown  In  Figure  3-16. 


package_dec1 


Figure  3-16:  Example  of  a  Package  Body  as  a  subunit 

3.  5.  5.  Tasks 

Task  specifications  can  appear  In  two  contexts,  as  a  task  type  and  as  a 
single  task  specification.  The  context  Is  distinguished  by  the  kind  of  the  defined 
Identifier  (type_ld.  var_kf).  A  task  body  Is  neither,  so  Oiana  has  additionally  a 
task_body_ld.  This  additional  node  Implies  that  there  are  two  defining  occur¬ 
rences  and  therefore  two  distinct  Diana  entitles  which  do  not  have  the  same 
attributes.  Although  there  are  different  nodes,  the  Oiana  structure  looks  similar 
to  the  solution  for  packages.  In  particular,  the  same  principles  are  applied  In 
the  presence  of  separate  compilation. 
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3.5.5. 1.  Task  Typos  and  Task  Bodios 

In  tho  caso  of  a  task  type  and  a  corresponding  body,  we  have  the  Diana 
structure  shown  in  Figure  3-17.  In  the  presence  of  separate  compilation,  the 
3m_f>ody  attribute  denotes  void  for  the  task  specification  and  stub  for  the 
stub  declaration.  This  approach  parallels  the  approach  used  for  for  packages 
and  subprograms.  Used  occurrences  of  the  task  Identifier  denote  the  typ*_ld; 
the  sm_flrat  for  the  task_body_id  also  references  the  type_td. 


typs 


Figure  3-17:  Example  of  a  Task  Type  and  Body 

3.  5.  5. 2.  Single  Tasks  and  Task  Bodies 

Single  tasks  are  represented  by  a  task_deo<  node  with  a  var_ld.  The  task 
specification  Is  given  as  an  anonymous  type  specification.  The  Diana  structure, 
nearly  the  same  as  the  structure  used  for  task  types,  is  shown  In  Figure  3-18. 
Used  occurrences  reference  the  var_ld :  the  amjlrat  attribute  of  the 
task_body_ld  also  references  the  var_ld. 

Note  that  in  the  case  of  an  address  specification  of  a  single  task,  the 
am_addraaa  of  the  var.ld  and  the  task_spec  are  both  set. 
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Figure  3-18:  Example  of  Single  Tasks 


3.5.6.  Qeneric  Units 

Like  subprograms  and  packages,  generic  units  can  have  several  declaration 
points:  the  specification  and  the  body  (and  possibly  the  stub  as  well).  In  order 
to  have  the  same  information  at  these  declaration  points,  the  Identifier  of  the 
body  of  the  generic  unit  has  to  be  a  generic_ld  with  the  same  attribute  values  as 
the  defining  occurrence  within  the  specification.  Thus  the  attribute 
am_gmn*rlc_param_js  points  to  the  list  of  generic  parameters  given  with  the 
specification,  and  the  attributes  sm_spe c  and  amjsody  are  set  as  in  the  case  of 
simple  subprograms  or  packages.  Note  that  for  generic  subprograms  the  sub¬ 
program  formats  are  treated  as  described  In  Section  3. 5. 3. 5.  The  Diana 
structure  for  a  generic  subprogram  is  illustrated  in  figure  3-19. 
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generic 


Figure  3-19:  Example  of  a  Generic  Body  as  a  subunit 

3.6.  Treatment  of  Instantiations 

In  this  section  we  describe  how  Diana  treats  instantiations  of  generic  units. 

An  obvious  implementation  would  copy  the  generic  unit  and  substitute  the 
generic  actual  parameters  for  all  uses  of  the  generic  formal  parameters  in  the 
body  of  the  unit.  This  substitution  cannot  be  done  If  the  body  of  the  generic 
unit  is  compiled  separately.  A  more  sophisticated  implementation  may  try  to 
optimize  instantiations  by  sharing  code  between  several  instantiations.  Therefore 
the  body  of  a  generic  unit  Is  not  copied  in  Diana  in  order  to  avoid  constraining 
an  Implementation.  Indeed,  an  instantiation  may  occur  in  the  absence  of  a 
generic  body. 

in  Diana  the  Instantiation  Is  performed  In  two  steps.  First,  a  normalized  list 
of  the  generic  parameters  is  created.  The  nodes  of  the  type  Instantiation  have 
the  semantic  attribute  sm_dec/_s  with  a  sequence  of  declarations.  This  attribute 
is  the  normalized  list  of  the  generic  parameters,  including  entries  for  all  default 
parameters.  The  values  of  this  attribute  are  determined  as  follows: 

•  For  every  generic  formal  In-parameter,  a  constant  declaration  Is 
created  (the  «m_pb/_def  refers  to  either  the  expression  given  or  to  its 
default  value). 
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•  for  avary  ganarlc  formal  In-out-parameter,  a  variable  declaration  la 
created  (the  am_obl_daf  refers  to  a  rename  node  which  indicates  the 
object  In  the  actual  list  that  Is  renamed  by  the  new  declaration) . 

•  for  every  generic  formal  typo,  a  subtype  declaration  is  created  (the 
amJypo_apoc  attribute  Is  a  constrained  node  with  a  void  constraint 
that  references  the  type  name  given  In  the  association  list) .  and 

•  for  every  generic  formal  subprogram,  a  new  subprogram  declaration  is 
created  (the  amjaody  attribute  references  a  rename  node  which  In¬ 
dicates  that  the  newly  created  subprogram  renames  either  the  sub¬ 
program  given  In  the  association  list  or  that  chosen  by  the  analysis 
as  the  default) . 

in  the  second  step  the  specification  part  of  the  generic  unit  Is  copied.  Every 
reference  to  a  formal  parameter  In  the  original  generic  specification  Is  changed 
to  reference  the  corresponding  newly  created  declaration.  If  a  formal  type  has 
discriminants,  references  to  them  are  changed  to  point  to  the  corresponding 
discriminants  of  the  base  type  of  the  newly  created  subtype. 

Examples  of  instantiations  are  presented  in  the  following  two  sections. 


3.6.1.  Instantiation  of  Subprograms 

The  generic  Instantiation  of  a  subprogram  Is  represented  by  the  structure 
shown  in  Figure  3-20.  We  use  procedures  as  an  example;  the  structure  for 
functions  is  similar.  Figure  3-20  Illustrates  the  Instantiation  of  the  following 
generic: 

generic 

UOK 7TH  i  INTEGER  i-  200 >  —  default  value 

type  ELEN  la  private; 

procedure  EXCHANGE  ( V  t  in  out  ELEM); 

•  •  • 

procedure  snap  is  new  exchange( elem  »  integer); 

The  procedure  node  of  the  subprogram_decl  contains  no  Information;  Its 
parameter  list  Is  empty.  The  instantiation  node  represents  the  generic  parameter 
associations;  It  Is  referenced  by  the  amjaody  attribute  of  the  proc_ld  node.  The 
instantiation  node  also  has  a  normalized  list  of  the  generic  parameters;  it 
contains  a  constant  declaration  of  '  LENGTH'  using  the  default  and  a  type 
declaration  of  the  subtype  'ELEM'  using  the  type  name  given  In  the  association 
list.  The  am_ppoc  attribute  of  the  proc_ld  node  references  the  header  of  the 
Instantiated  subprogram.  It  is  obtained  by  copying  the  generic  subprogram's 
header  and  replacing  references  to  the  generic  formal  parameters  with  references 
to  the  new  subtype  declaration  and  constant  declaration. 
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Figure  3-20:  Instantiation  o4  a  Generic  Procedure 
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3.6.2.  Inatantlatlon  of  Packages 

Tha  ganarlc  Inatantlatlon  of  a  package  la  represented  In  Diana  by  the  structure 
shown  In  Figure  3-21.  Tha  Inatantlatlon  node  Is  referenced  by  tha 
sm_body  attribute  of  tha  package  Identifier.  Tha  package  specification  Is  con¬ 
structed  by  copying  the  specification  of  the  generic  unit  and  replacing  all 
references  to  generic  formal  parameters  with  references  to  their  corresponding 
actual  parameters.  The  resulting  specification  Is  denoted  by  the 
sm_spec  attribute  of  the  package  Identifier. 

3.7.  Treatment  of  Renaming 

The  renaming  of  entities  does  not  Introduce  further  problems.  However,  the 
Diana  representation  for  some  renamings  may  not  be  obvious.  This  section 
clarifies  how  Diana  treats  entitles  Introduced  by  a  renaming  declaration. 

Renaming  of  objects  and  exceptions  are  simple  and  not  discussed  here. 
Note  that  an  Identifier  which  renames  a  constant  object  has  to  be  a  const_ld. 
Constant  objects  are  constants,  discriminants,  and  parameters  of  mode  In.  as 
well  as  components  of  constant  arrays. 

3.7.1.  Renaming  of  Subprograms 

The  renaming  declaration  for  a  subprogram  must  repeat  the  header  of  the 
renamed  Item.  This  header  can  be  denoted  by  the  sm_&pac  attribute  of  the 
newly-introduced  subprogram  Identifier.  The  rename  Information  Is  referenced  by 
the  smjaody  attribute,  since  the  actual  body  can  be  obtained  from  the  rename 
Information.  The  structure  Is  Illustrated  In  Figure  3-22. 

Note  that  an  identifier  which  renames  an  entry  or  a  member  of  an  entry 
family  has  to  be  an  entryjd.  It  Is  possible  In  Ada  to  rename  an  enumeration 
literal  as  a  function.  In  such  a  case  the  Identifier  that  renames  an  enumeration 
literal  haa  to  be  an  enum_ld. 

3. 7. 2.  Renaming  of  Packages 

The  renaming  declaration  of  a  package  doea  not  repeat  the  package 
speclficetlon.  The  am^spec  attribute  of  the  new  package  Identifier  therefore 
references  the  original  package  specification.  In  order  that  the  specification  is 
always  present  for  a  package  Identifier.  The  am_pody  attribute  denotes  the 
rename  node.  The  resulting  structure  is  illustrated  In  Figure  3-23. 
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package_dec1 
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Ptgur*  3-21:  Instantiation  of  a  3*n*rks  Paokag* 
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Flgura  3-22:  Renaming  a  Procedure 
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decl.sl 


decl_s2 


Flgura  3-23:  Ranamlng  a  Package 
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3. 7. 3.  Renaming  of  Tasks 

Task  ob|*cts  can  ba  renamed  Ilka  othar  objects.  Tha  task  ranamlng  Is 
treated  lust  Ilka  tha  ranamlng  of  objacts.  Task  typas  ara  ranamad  Just  Ilka  othar 
typas.  Nota  that  thara  Is  no  othar  ranamlng  daclaratlon  for  tasks. 

3.6.  Implamantation  Oapandant  Attrlbutaa 

Raprasantatlon  Indapandance  was  a  principal  design  goal  of  Diana.  Diana 
does  not  fore*  an  implamantation  strategy  on  either  a  Front  or  Back  End— or  on 
any  othar  tool  for  that  matter.  Tha  description  of  Diana  deals  with  this  problem 
(In  part)  by  using  private  typas  for  attributes  that  ara  to  b*  implamantation 
defined.  An  Implamantation  has  the  freedom  to  choose  a  suitable 
raprasantatlon.  but  it  must  support  tha  corresponding  attributes.  Thus  an  Im¬ 
plementation  must  provide  appropriate  packages  In  which  the  attribute  typas  are 
defined,  together  with  the  necessary  access  operations. 

In  this  section  we  describe  tha  purpose  of  tha  attributes  In  detail  and  sketch 
possible  internal  and  external  representations  of  them. 

3.8.1.  Evaluation  of  Static  Expressions 

Tha  language  requires  that  static  expressions  be  evaluated  at  compile  time  In 
particular  contexts  (see  Ada  LRM  (81.  Section  4.9).  This  evaluation  can  ba 
don*  either  by  tha  cod*  generator  or  by  the  Front  End  (with  target  and  host 
Independent  arithmetic) .  Both  ways  are  supported  by  Diana.  Since  the  Diana 
structure  may  be  used  as  input  to  the  Front  End  In  the  case  of  separate 
compilation,  the  latter  solution  has  the  advantage  that  the  previously  evaluated 
expression  can  be  used  In  the  currently  compiled  unit.  For  this  purpose  every 
expression  node  that  can  have  a  static  value  has  an  attribute  amjra/u*  whose 
type  Is  Implementation  dependent1.  Its  external  representation  Is  discussed  In 
Chapter  5.  The  Implementation  of  the  type  must  provide  for  a  distinguished 
value  of  this  attribute  which  Indicates  that  the  expression  la  not  evaluated.  Diana 
does  not  provide  for  non-static  values  to  be  computed,  even  if  an 
Implementation's  semantic  analyzer  Is  capable  of  evaluating  some  such  expres¬ 
sions  (see  Section  1.1.3). 
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3.8.2.  Representation  of  Idantlflars  and  Numbers 

The  attributa  typaa  symbol  _jop  and  numbor_r»p  ara  not  daflnad  In  Oiana. 
Their  axtarnal  raprasantation  la  diacuaaad  In  Chaptar  5.  Thalr  Intarnal  represen- 
tatlon  la  not  apaclflad.  ao  that  Diana  doaa  not  impose  a  apaclal  Implamantatlon. 

3.8.3.  Sourca  Poaitlona 

Sourca  position  la  Important  for  arror  massages  from  tha  compllar.  it  may 
also  ba  useful  to  other  tools  that  work  with  tha  Diana  structure,  such  as 
Interpreters  or  debuggers. 

Tha  structure  of  this  attributa  Is  not  defined  by  Diana  since  each  computer 
system  has  Its  own  notation  of  a  position  in  a  sourca  file.  Moreover  this 
notation  can  vary  between  tools  of  tha  same  environment;  an  Interactive  syntax* 
directed  editor  may  have  a  different  type  of  source  position  than  a  batch-oriented 
compiler  for  example. 

Diana  does  not  require  that  this  attribute  be  supported  by  every  Implementation 
(see  Section  1.1.3).  Any  Implementation  that  does  support  this  attribute  must 
define  a  distinguished  value  for  this  type  for  undefined  source  positions,  which 
can  be  used  if  nodes  are  created  which  have  no  equivalence  In  the  source  file. 

The  library  manager  for  certain  implementations  may  need  a  value  Indicating 
which  compilation  unit  a  Diana  entity  comes  from.  This  Information  appropriately 
belongs  with  the  source  position,  and  should  be  incorporated  into  such  an 
Implementation's  definition  of  the  private  type. 

3.8.4.  Comments 

The  /x_commenfs  attribute  Is  used  for  recording  comments  from  the  source 
program.  The  structure  of  this  attribute  is  not  defined  by  Diana  since  every 
Implementation  may  have  Its  own  method  of  attaching  comments  to  Oiana  nodes. 
A  generalized  method  for  attaching  comments  to  nodes  is  impractical:  there  Is 
no  method  that  will  be  accurate  for  all  commenting  styles.  We  envision  local 
commenting  standards  that  will  be  enforced  to  match  the  Implementation  choices 
for  attaching  comments  to  tree  nodes.  Note  that  support  of  the  lx_commonta 
attribute  Is  not  required  for  an  implementation  to  be  considered  a  Diana  producer 
or  a  Oiana  consumer. 
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9.8.5.  Predefined  Operators  and  Built-In  Subprograms 

Tha  am  _p  par  at  or  attrlbuta  Is  usad  to  Idantlty  pradafinad  oparators  and 
implamantatlon-dapandant  built-in  subprograms2.  Usar-daflnad  oparators  ara 
traatad  as  functions  In  Oiana  and  ara  not  considarad  hara.  Tha  pradafinad 
oparators  and  built-in  subprograms  ara  traatad  spacially  bacausa  It  is  Important 
Information  for  tha  coda  ganarator  and  for  an  optimizer. 

Tha  typa  of  this  attribute  Is  Implementation-defined.  A  likely  implementation 
is  an  enumeration  typa  with  at  least  one  literal  for  each  predefined  language 
operator.  Tha  refinement  of  Diana  given  In  chapter  2  gives  the  minimum  subset 
of  oparators  that  must  be  supported.  An  Implementation  can  obviously  support 
further  oparators  which  can  be  added  to  this  enumeration. 

Tha  means  by  which  this  information  Is  made  known  to  the  Front  End  is  not 
specified  in  Diana.  We  provide  only  for  representing  the  result  of  semantic 
analysis:  If  the  Front  End  recognizes  that  a  compilation  unit  uses  one  of  tha 
built-in  subprograms,  then  the  used_name_ld  of  the  subprogram  Is  changed  to  a 
us*d_bltn_id  whose  am__operator  attribute  Is  set  to  denote  the  particular  built-in 
subprogram  that  was  used. 

9.9.  Equality  and  Assignment 

The  Diana  representation  assumes  a  well-defined  notion  of  equality  for  all 
attribute  typos,  including  tree-valued  attributes.  An  implementation  must  provide 
an  equality  comparison  operation  so  that.  for  Instance,  tha 
am_fype_spe c  attribute  of  two  entitles  of  the  same  type  will  be  equal  and  will  not 
be  equal  to  the  am_tYP9_jip9C  attribute  of  any  entity  of  different  typa. 

If  an  implementation  Implements  nodes  as  access  types  and  tree-valued 
attributes  as  pointers,  than  tha  equality  comparison  can  be  a  simple  pointer 
equality.  Oiana  does  not  force  this  Implementation,  however.  It  is  still  possible 
for  an  Implementation  to  make  separata  copies  of  a  defining  occurrence.  For 
example,  consider  a  situation  where  a  separately  compiled  unit  A  defines  a  type, 
two  other  units  B  and  C  use  this  typa  to  declare  variables  X  and  Y.  and  a  fourth 
unit  D  references  both  X  and  Y.  it  Is  possible  for  an  implementation  to  decide  to 
copy  some  type  Information  from  A  Into  B  and  C.  However,  a  tool  processing 


*For  example,  an  Implementation  may  "bum  in"  knowledge  of  the  LOQ  function  from  library  package 
MATH_UB. 
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the  repreeentatlon  for  unit  D  must  ba  abla  to  compare  the  sm_fype_Jspec  at¬ 
tributes  of  X  and  Y  for  equality.  Thus  the  Implementation  making  the  copies 
must  keep  enough  Information  In  its  representations  to  be  able  to  tell  that  the 
copies  are  copies  of  the  same  thing.  One  possible  solution  is  to  attach  a 
unique  key  to  every  entry  and  to  copy  the  key  along  with  the  other  portions  of 
the  entity.  The  equality  test  can  use  this  key  for  comparison. 

Diana  imposes  a  further  requirement  on  Implementations  of  attribute-storing 
procedures.  If  an  Implementation  stores  an  attribute  of  a  defining  occurrence  or 
a  type  specification,  this  change  must  be  visible  to  all  uses  of  such  entitles. 
Once  again,  making  the  change  visible  is  easy  If  the  corresponding  attributes  in 
the  uses  are  Implemented  as  pointers.  In  the  case  where  an  implementation 
has  copies  of  such  entitles,  the  store  procedure  must  ensure  that  all  copies 
which  might  be  referenced  are  updated  appropriately. 

Note  that  the  duplication  of  tree  structures  Imposed  by  Diana,  especially  those 
described  in  Sections  3. 4. 2. 3  and  3.6.  are  not  copies  in  the  sense  of  this 
section.  They  represent  Information  for  new  obiects.  either  of  derived  types  or 
of  instantiated  units.  The  new  obiects  must  be  different  from  the  original  ones. 

Diana  does  make  a  requirement  about  the  value  of  tree-valued  attributes  In 
the  external  ASCII  form  (Chapter  5) .  Tree-valued  attributes  that  are  equal  must 
be  represented  externally  by  a  reference  to  the  same  tree:  they  must  essentially 
share  the  value.  This  Issue  is  addressed  more  completely  in  Chapter  5. 

3. 10.  Summary  of  Attributes 

A  short  description  of  all  attributes  of  Diana  closes  the  Rationale.  We  do  not 
describe  the  structural  attributes  ( for  the  tree) :  this  description  is  in  the 
AFD  and  can  be  deduced  from  the  concrete  syntax  of  Aoa  (which  Is  Included  In 
the  Diana  definition  for  convenience) .  The  remaining  three  attribute  classes  are 
described.  If  they  are  already  explained  In  the  Rationale,  then  only  a  reference 
to  that  section  appears. 

3.10.1.  Lexical  Attributes 

Ixjnumrap:  Internal  (or  external)  representation  of  a  numeric  literal, 

the  type  is  Implementation  dependent,  see  3. 8. 2. 

Ix_d»fault\  Is  of  type  Boolean.  Indicates  whether  the  mode  of  an 

In-parameter  was  specified  (False)  or  defaulted  (True). 


Rational* 
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lx_prat!x: 

Ixjtrcpoa : 

lx_aymrap : 

lx_commanta : 

3.  10. 2.  Semantic 
am_actual_dalta 

am_fiddreaa : 

am_baao_type: 

am_plta: 

am_pody: 

am_comp_apac: 

am_conatralnt : 
amjBontrollad : 


is  ot  type  Boolean.  Indicates  whether  a  function  call  was 
written  using  prefix  (True)  or  Infix  (False)  notation,  see 
3.3.4. 

source  position  of  the  corresponding  node,  the  type  Is 
Implementation  dependent,  see  3.8.3. 

Internal  (or  external)  representation  of  a  symbol  (/.*..  an 
Identifier  or  a  string) .  the  type  Is  Implementation 
dependent,  see  3.8.2. 

representation  of  comments  from  the  program  source,  the 
type  is  Implementation  dependent,  see  3. 8. 4. 


Attributes 

Is  of  universal  rational  number  type,  contains  the  value  of 
the  predefined  attribute  'ACTUAL^ DELTA. 

denotes  the  expression  given  In  a  representation 
specification  for  the  predefined  attribute  ‘ADDRESS.  It  Is 
void  If  the  user  has  not  given  such  a  specification. 

denotes  the  base  type  of  a  subtype,  see  3. 4. 2.  2. 

Is  of  a  universal  Integer  type,  contains  the  value  of  the 
predefined  attribute  'BITS. 

denotes  the  body  of  a  subprogram  or  package.  It  Is  void  If 
the  body  or  stub  are  not  In  the  same  compilation  unit,  see 
3.2.1.  For  instantiated  or  renamed  entitles  It  has  the  type 
Instantiation  or  rename  (see  3.6  or  3.7.  respectively). 
For  generic  formal  subprograms  it  denotes  the 
FORMAL_SUBPROQ_DEF.  If  the  pragma  INTERFACE  has 
been  applied  to  the  subprogram.  It  denotes  the  defining 
occurrence  of  the  given  language  name  in  the  predefined 
environment  see  Appendix  I) . 

refers  to  the  representation  specification  for  a  record  com¬ 
ponent  or  discriminant. 

for  expressions  see  3.  4.  3,  for  subtypes  see  3.  4. 2. 2. 

indicates  whether  the  pragma  CONTROLLED  has  been  ap¬ 
plied  to  the  type. 

belongs  to  an  Instantiation  node.  It  refers  to  a  normalized 
parameter  list  which  contains  a  declaration  (DECL)  node  for 
all  formal  parameters,  see  3.6. 
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am_dafn :  danotas  the  defining  occurrence  of  a  used  identifier,  sea 

3.3. 


am -.discriminants:  danotas  the  sequence  of  discriminants  given  for  a  record  or 
(limited)  private  type,  may  be  empty,  see  3.5. 1.3. 

am_axcaptlon_dat:  denotes  the  EXCEPTION_DEF  subtree  of  an  exception  decla¬ 
ration.  which  Is  void  in  normal  cases  and  a  rename  node  If 
It  Is  a  renaming  declaration. 

am_axp_fypa :  denotes  the  type  of  the  expression  as  the  result  of  over¬ 

loading  resolution,  see  3.4.3. 

smjlrat:  refers  to  the  first  occurrence  of  a  multiply  defined  Identifier, 

see  3. 3. 3. 


am  generic,  param  a : 

denotes  the  list  of  generic  parameters  of  a  generic  sub¬ 
program  or  package. 

smjnlt_0xp :  denotes  the  initialization  expression  given  for  numbers.  In 

parameters,  record  components,  and  discriminants. 

amjocatlon:  denotes  the  location  of  a  subprogram;  It  may  be  (a)  void. 

(b)  the  Identifier  (pragma_ld)  of  the  pragma  INLINE  If  that 
has  been  applied  to  the  subprogram,  or  (c)  an  expression 
supplied  by  the  user  in  an  address  specification  for  the 
subprogram. 

am_normall  zeef_comp_a : 

denotes  the  normalized  list  of  values  for  a  record  aggregate 
or  for  a  discriminant  constraint.  Including  default  values. 


am_fiormallz»d_param_s : 

denotes  the  normalized  list  of  parameters  for  a  procedure, 
function,  or  entry  call.  Including  the  default  parameters. 

am-.obl_.daf:  denotes  the  Initialization  expression  of  an  object.  It  Is  void 

If  none  is  given.  In  the  case  of  a  renamed  object.  It 
denotes  the  rename  nod*  of  the  declaration  structure. 


amjabl-typa:  denotes  the  type  specification  of  a  declaration  (constants. 

parameters,  discriminants,  numbers,  variables,  enumeration 
literals,  and  tasks) .  For  deferred  constants  see  3.  5.  5.  In 
case  of  numbers  It  denotes  one  of  the  universal  types,  see 
Appendix  I. 

am-pparator:  denotes  on*  of  the  predefined  operators  or  built-in  sub¬ 

programs.  see  3.8.5. 


Rational* 
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am_packlng : 

am_poa: 

am_record_apec : 
am_rap: 

amjaln: 

am_ape  c: 

am_stm : 

am_atorage_alzB: 

amjstub: 

am_type_apoc: 

amjyp*_atruct: 

amjtalua: 


indicates  whether  the  pragma  PACK  has  been  applied  to  that 
type. 

Is  of  universal  Integer  type,  contains  the  value  of  the 

predefined  language  attribute  'POS  of  an  enumeration  literal. 

refers  to  the  representation  specification  for  a  record. 

Is  of  universal  integer  type,  contains  the  value  of  the 

predefined  language  attribute  ‘VAL  of  an  enumeration  literal, 
which  can  set  by  the  user.  See  also  3.4. 2.3. 

denotes  the  expression  given  In  a  representation  specifica¬ 
tion  for  the  predefined  language  attribute  'SIZE;  It  Is  void  If 
the  user  has  not  given  such  a  specification. 

denotes  the  specification  of  a  subprogram  or  package.  In 

the  case  of  subprograms.  it  Is  Its  header  (for 

instantiations,  see  3.6).  In  the  case  of  packages.  It  Is 
the  package  specification.  For  Instantiated  packages,  see 
Section  3. 6  and  for  renamed  packages,  see  Section  3. 7. 
In  the  case  of  a  generic  unit,  it  is  the  generic  header  of 
the  unit. 

denotes  the  statement  to  which  a  label,  loop  name,  or 
block  name  definition  belongs  or  the  loop  which  is  left  by 
an  exit  statement. 

denotes  the  expression  given  in  a  representation 
specification  tor  the  predefined  language  attribute 
'STORAGE_SIZE:  It  is  void  If  the  user  has  not  given  such  a 
specification. 

refers  to  the  defining  occurrence  of  the  stub,  see  3. 5.  3.  3. 

denotes  the  specification  which  belongs  to  a  type  Identifier; 
for  private  and  incomplete  types,  see  Section  3.5.1.  for 
tasks  and  task  body  Identifier,  see  Section  3.  5.  5. 

denotes  the  structural  Information  of  a  subtype,  see 
3. 4.  2.  2.  or  derived  type,  see  3.  4. 2.3. 

contains  the  value  of  the  corresponding  expression  If  It  Is 
statically  evaluated.  Its  type  is  implementation  dependent, 
see  3. 8. 1. 
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3.10.3.  Code  Attributes 

cdjmpljslze :  of  type  universal  integer,  contains  the  value  of  the  attribute 

'SIZE  for  static  subtypes.  It  may  be  less  than  a  user 
defined  size. 

3.10.4.  Unnecessary  Attributes 

There  are  a  number  of  attributes  one  might  expect  of  semantic  analysis  that 
are  not  explicitly  represented  in  Diana  since  they  are  very  easy  to  recompute. 

The  floating  point  attributes  corresponding  to  'MANTISSA.  'EMAX.  'SMALL, 
'LARGE,  and  'EPSILON  can  all  be  computed  from  'OIGITS.  which  is  required  to 
be  a  static  expression.  Formulae  for  these  attributes  are  given  in  Sections 
3.5.7  and  3.5.8  of  the  Language  Reference  Manual,  and  are  reproduced  here 
for  convenience: 

'MANTISSA  =  celling  ('DIGITS  *  Ln(10)  /  Ln(2>) 

'EMAX  =  'MANTISSA  *  4 

'SMALL  =  .5  *  2** (-'EMAX) 

'LARGE  *  (1.0  -  'EPSILON)  *  2*«'EMAX 

'EPSILON  =  2.  0**(-'MANTISSA) 

For  fixed  point  types.  all  attributes  can  be  defined  In  terms  of 
' ACTU Al _ DELT A  and  'BITS. 
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CHAPTER  4 

DEFINITION  OF  THE  DIANA  OPERATIONS 


Recall  that  Diana  Is  an  abstract  data  type.  By  the  nature  of  an  abstract  data 
type  as  Implemented  in  a  programming  language,  all  that  neeo  oe  known  about 
the  type  are  the  functions  and  procedures  that  operate  on  objects  of  the  type. 
Thus  to  realize  the  abstract  type  Diana  In  some  programming  language,  all  that 
Is  needed  is  to  write  those  functions  and  procedures.  In  a  language  like  Ada  It 
is  possible  to  separate  the  specification  of  these  functions  and  procedures  from 
their  Implementation. 

in  this  chapter  we  provide  an  Ada  specification  (but  not  implementation)  of 
the  Interface  to  the  necessary  functions  and  procedures  to  define  Diana.  Fur¬ 
ther.  we  suggest  how.  in  general,  an  Implementation-specific  package  may  be 
derived  from  an  IDL  definition.  Since  the  derivation  of  packages  from  an  IDL 
description  Is  a  complex  topic,  we  only  sketch  one  possible  derivation  for  one 
particular  language.  A  detailed  discussion  of  the  package  derivation  process  is 
given  in  the  IDL  Formal  Description  [91. 

4. 1 .  The  Diana  Operations 

Every  object  of  type  Diana  is  the  representation  of  some  specific  Ada  program 
(or  portion  of  an  Ada  program).  Specifically,  it  may  be  thought  of  as  the 
output  from  passing  that  program  through  the  Front  End  of  an  Ada  compiler.  A 
minimum  set  of  operations  on  the  Diana  type  must  Include  the  following  functions 
and  procedures: 

typesetter  Such  a  function  permits  the  user  to  determine  of  a  given 

object  what  its  type  is.  In  Diana  terms.  If  an  object  Is 
known  to  belong  to  some  specific  node  class,  the  function 
determines  the  object's  node  type. 

selector  Such  a  function  returns  the  value  of  a  specific  attribute  of  a 

node. 

constructor  Such  a  procedure  builds  a  node  from  its  constituent  parts, 

or  changes  the  value  of  an  attribute  of  a  node. 

In  addition,  operators  are  necessary  to  determine  the  equality  of  Diana  objects. 
Specifically,  are  a  given  pair  of  Instances  of  a  Diana  type  in  fact  the  same 
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Instance,  as  opposed  to  equivalent  ones1?  in  case  there  are  variables  of  this 
abstract  data  type,  an  assignment  operator  Is  necessary  as  well. 

4.2.  Diana's  Use  of  Other  Abstract  Data  Types 

An  IDL  definition  (such  as  the  definition  of  Diana  in  Chapter  2)  Is  built  upon 
subsidiary  abstract  data  types.  These  Include  those  used  in  the  IDL  notation 
(such  as  integer.  Boolean.  Seq  of)  as  well  as  Implementation-defined  attribute 
types  (such  as  source_posltlon.  symbol_rep.  and  so  on).  All  of  these  except 
seq  Of  have  the  same  operations  as  described  above.  It  must  be  carefully  noted 
that  for  the  scalar  types  (Integer.  Boolean)  there  Is  usually  no  distinction  drawn 
between  equality  and  equivalence.  Whenever  doing  so  Is  necessary,  we  carefully 
draw  such  a  distinction. 

The  sequence  type  seq  Of  can  be  considered  as  a  built-in  type  that  has  a 
few  special  operators.  Specifically,  there  must  be  a  way  to  check  if  a  sequence 
Is  empty  and  to  fetch  Items  from  a  sequence.  Additionally,  there  must  be 
operators  for  adding  and  removing  items  from  a  sequence. 

The  implementation  defined  types  must  have  all  the  operations  appropriate  to 
them  as  well  as  those  described  above  for  attributes  and  nodes. 

4.3.  Summary  of  Operators 

This  section  summarizes  the  operations  described  above. 

The  operations  on  nodes  are 

•  create  a  node: 

•  fetch  the  value  of  an  attribute  of  a  given  node; 

•  set  the  value  of  an  attribute  of  a  given  node; 

•  compare  two  nodes  to  see  if  they  are  the  same  node;  and 

•  assign  a  specific  node  to  a  variable. 

•  The  operators  defined  for  the  IDL  sequence  type  (an  ordered  list  of  nodes  of 

the  same  class)  are 

•  create  a  sequence  of  a  given  type; 

•  select  an  element  of  a  sequence; 

•  add  an  element  to  a  sequence; 


1This  distinction  is  addressed  further  in  Section  3.8  on  page  123. 
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•  remove  an  element  from  a  sequence; 

•  compare  two  sequences  to  see  If  they  are  the  same  sequence;  and 

•  assign  a  sequence  to  a  variable  of  sequence  type. 

The  operators  required  for  the  IDL  scalar  types  (integer,  national,  and 
Boolean)  are 

•  create  a  scalar; 

•  compare  two  scalars  to  see  If  they  are  equal  (/.e. .  the  same 
scalar) ;  and 

•  assignment. 


4.4.  Qeneral  Method  for  Deriving  a  Package  Specification  for  Diana 

To  derive  a  general  package  specification  for  defining  this  abstract  data  type 
called  Diana,  further  decisions  concerning  the  Implementation  model  need  to  be 
made.  For  example,  one  must  decide  how  to  represent  the  various  Diana 
objects.  After  these  decisions  have  been  made,  a  straightforward  process  can 
be  applied  to  derive  the  package  specification  from  the  Diana  domain.  A  formal 
method  for  specifying  these  decisions  is  presented  in  the  IDL  formal  description. 
Indeed,  an  IDL  tool  would  produce  such  a  package  automatically  from  the 
definition  of  Diana  In  Chapter  2.  For  the  purposes  of  this  document,  the 
following  discussion  is  sufficient. 

The  Implementation  model  must  deal  with  two  separate  areas  of  concern. 
First,  there  are  the  implementation  restrictions  imposed  by  the  choice  of  the 
source  language  that  the  Diana  type  Is  being  implemented  In.  Secondly,  there  Is 
the  choice  of  corresponding  entities  In  the  Implementation  language  for  entitles  In 
the  Diana  domain  (f.e.,  how  Diana  objects  are  represented).  These  decisions 
can  be  driven  by  the  design  considerations  of  tools  that  expect  to  use  the  Diana 
type,  as  well  as  by  specific  restrictions  of  the  host  system. 

The  general  steps  are  as  follows: 

■  representation  of  IDL  types.  An  Implementation  for  each  of  the  IDL 
types  must  be  chosen.  Normally  for  the  scalar  types,  the  Implemen¬ 
tation  language  supports  an  equivalent  (or  close  enough)  abstract 
type.  For  the  sequence  type  and  the  Implementation  defined 
types,  the  same  decisions  need  to  be  made,  and  an  abstract  data 
type  for  these  derived  and  specified.  (The  Diana  domain  specification 
provides  a  handle  on  the  abstract  data  types  for  the  implementation 
defined  types. ) 

•  representation  of  node  classes.  The  class  names  of  the  Diana  lan¬ 
guage  must  be  handled  by  the  package  derivation  process,  because 
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tha  types  of  tha  attrlbutas  ara  daflnad  using  thasa  mata-varlablas. 

•  representation  of  nodes.  Tha  noda  representation  choice  must  permit 
attribute  values  to  be  associated  with  the  noda.  since  each  specific 
Instance  of  a  noda  may  have  different  attribute  values. 

•  method  of  defining  operators.  Tha  operators  In  tha  language  must  b* 
specified  either  as  functions  and  procedures  In  the  Implementation 
language  or  by  equating  them  to  specific  operations  already  in  the 
Implementation  language. 


4.5.  Deriving  a  Specific  ADA  Package 

To  derive  a  specific  Ada  package,  we  apply  the  general  method  as  outlined  in 
the  previous  section.  First,  we  choose  an  Implementation  model  of  an  abstract 
data  type  defined  as  a  single  package.  A  single  Ada  private  type  Is  used  to 
define  all  nodes  in  the  Oiana  domain.  All  operations  are  calls  on  procedures  or 
functions  specified  in  the  package.  Having  made  these  decisions,  we  then 
address  the  following  points: 

•  representation  of  IDL  types.  The  IDL  Boolean  type  could  be  Imple¬ 
mented  directly  by  the  ADA  boolean  predefined  type.  However,  the 
IDL  integer  and  Rational  types  would  have  to  be  represented  some¬ 
how  so  as  to  be  able  to  represent  arbitrarily  large  quantities,  and  (in 
the  case  of  rationale)  to  represent  them  exactly  with  no  approximation2 

Using  the  ADA  predefined  types  INTEGER  and  float  would  not  be 
adequate. 

For  the  sequence  type  Seq  of.  we  Include  a  private  type  definition 
and  primitive  operations.  The  operations  permit  creation  of  an  empty 
sequence  ( Make) .  functions  to  add  an  element  at  the  beginning 
(Insert)  and  end  (Append)  of  a  sequence,  and  functions  for  selecting 
the  first  element  of  a  sequence  ( Head)  and  the  remainder  of  a 
sequence  (Tail) .  There  is  also  a  function  to  determine  if  a  list  Is 
empty  (ls_Empty).  Note  that  additional  functions  and  procedures  for 
this  type  could  be  added. 

•  representation  of  node  classes.  Since  a  single  type  Is  being  used  to 
represent  all  nodes  In  the  domain,  the  dir*'r5tlon  between  different 
classes  Is  not  necessary. 

•  representation  of  nodes.  A  single  private  type  (called  Tree)  Is 
provided  for  all  the  node  names  defined  in  the  Diana  domain.  An 
enumerated  type  (called  Node_Name)  Is  defined  which  provides  a 


2Theae  requirement*  ere  tpetteS  out  in  the  Ada  LRM,  which  require*  that  tome  arithmetic  performed 
at  compile  time  be  done  exactly. 
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name  for  all  the  various  nodes  defined  In  the  Diana  domain.  An 
additional  function  ( named  Kind  and  returning  a  result  of  type 
Node_Name)  Is  added  to  the  Tree  type  to  distinguish  between  different 
node  kinds. 

•  method  of  defining  operators.  The  create  operator  lor  the  various 
nodes  becomes  a  single  function  that  takes  a  Node.Name  and  returns 
a  new  Tree  node  with  most  of  Its  attributes  not  defined.  Each  of  the 
Diana  attributes  has  a  corresponding  procedure  and  function  in  the 
package  specification  that  respectively  modify  and  fetch  the  value  of 
an  attribute.  The  procedure  and  function  both  take  the  specific  Tree 
node  as  an  argument.  The  procedure  takes  an  additional  argument 
which  gives  the  new  value  for  the  attribute;  the  function  returns  the 
corresponding  attribute  value. 

The  comperlaon  operators  for  the  nodes  and  for  sequences  are  the  built-in 
Ada  comparison  operators  '/*’>  which  are  defined  for  private  types.  The 

comparison  operators  for  the  scalar  types  are  not  defined  In  this  package.  The 
Ada  language  provides  all  create  operations  for  the  scalar  types.  The  eaalgnment 
operators  are  the  pre-deflned  Ada  assignment  operators  for  variables  of  the 
private  types.  Except  for  these  assumptions  on  the  use  of  built-in  operations, 
the  full  Ada  package  Is  given. 

A  few  facts  are  Important; 

•  Because  some  of  the  Diana  node  types  conflict  with  Ada  reserved 
words,  we  choose  to  prefix  ail  node.names  with  the  prefix  "dn_’ 

(short  for  Diana)  . 

•  Remember  that  this  specification  defines  a  minimal  set  of  operations; 
Implementations  may  augment  it  with  other  useful  ones  for  particular 
applications. 

•  We  have  added  an  additional  type  (ARITIES)  and  several  procedures 
and  functions  (ARITY,  Sonl.  Son2.  and  8on3)  which  are  mentioned 
In  the  Ada  Formal  Definition  and  which  are  very  useful  in  the  tree 
traversals  essential  to  many  phases  of  compilers,  as  well  as  other 
tools. 


4.9.  The  Diana  Package  In  Ada 

A  summary  of  essential  points  of  the  Ada  package  specification  for  Diana 
appears  in  Figure  4-1  on  page  134.  For  ease  of  understanding,  the  figure 
contains  only  as  much  of  the  package  as  fits  onto  one  page. 

The  package  defines  and  makes  available  the  following  types,  functions,  and 
procedures: 
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package  Diana  is 

type  Tree  is  private;  —  a  Diana  node 

type  3EQ_T%PE  is  private;  —  sequence  of  noda* 

typa  hooe_nane  is  —  anune ration  class  for  noda  n«— 

(  —  about  140  dif farant  nod*  typas 

)> 

—  Traa  constructor*. 

function  MAKE  (ci  in  NOOE_NAME)  zaturn  TREE; 

procedure  DESTROY  <  t *  in  TREE); 

function  KIND  (ti  in  TREE)  zaturn  NOOEJNAME; 

—  Traa  travarsars  Cron  th*  Ada  roraal  Definition. 

typo  ARITIE3  is  (nullary,  unary,  binary,  ternary,  arbitrary); 

function  ARITT  ( t «  in  TREE)  return  ARITIE3; 

function  SON1  (ti  in  TREE)  return  TREE; 

procedure  SONl  ( t:  in  out  TREE;  vi  in  TREE); 

function  S0N2  (ts  in  tree)  zaturn  TREE; 

pzooadur*  SON2  (tt  in  out  TREE;  Vt  in  TREE); 

function  SONS  (ti  in  TREE)  return  TREE; 

procedure  SON3  (ti  in  out  TREE;  at  in  TREE); 


—  Handling  of  list  constructs, 
function  HEAD  (li  in  SEQJTYPE) 

function  TAIL  (It  in  SEQJTYPE) 

function  MAKE 

taction  isjwpty  (li  in  SEQJTYPE) 
function  INSERT  (It  in  out  SEQ.TYPE; 

it  in  TREE) 

taction  APPEND  (It  in  out  SEQJTYPE; 

it  in  TREE) 


return  tree;  —  lisp  cm 
zaturn  seqjtype;  —  lisp  cdr 
return  seqjtype; 

—  return  anpty  list 
zaturn  BOOLEAM; 

return  3EQ  TYPE; 

—  inserts  i  at  start  of  1 

return  SEQJTYPE; 

—  inserts  1  at  and  of  1 


—  Handling  of  LIST  attribute  of  list  constructs. 
procedure  LIST  (tt  in  out  TREE;  vt  in  SEQJTYPE); 
taction  LIST  (tt  la  TREE)  return  SEQJRPE) 

—  Structural  Attributes. 

proosdure  AS_ACTUAL  ( t*  in  out  TREEl  vt  in  TREE); 

taction  A3_ACTUAL  (ti  in  TREE)  return  TREE  ;  —  assoc 

•  •  • 

—  followed  by  functions  and  procedures  for  about  100  atti  utes  . 
private 

—  To  be  filled  in... 


and  Diana; 


Figure  4-1:  Sketch  of  the  Diana  Package 
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type  TREE  An  object  of  this  private  type  Is  a  node  of  the  Diana 

structure. 

type  SEQ.TYPE  An  object  of  this  private  type  Is  a  sequence  of  nodes  of  the 
same  class. 

type  NODE_NAME  This  Is  an  enumeration  type  providing  an  enumeration  literal 
for  each  kind  of  Diana  node. 

function  MAKE  This  function  creates  and  returns  a  Diana  node  of  the  kind 
which  is  its  argument.  Note  that  it  Is  overloaded  so  as 
also  to  be  able  to  create  an  empty  list. 

procedure  DESTROY 

This  procedure  indicates  that  a  node  is  no  longer  required. 

function  KINO  Given  a  node,  this  function  returns  Its  node-kind. 

type  ARITIES  This  enumeration  type  provides  a  literal  for  each  number  of 
structural  children  a  node  might  have. 

ffl 

function  SONh  For  k  =  1.  2.  3,  each  such  function  returns  the  k 

offspring  of  a  node. 

u. 

procedure  SONk  For  k  -  1.  2.  3.  each  such  procedure  stores  a  new  k 
offspring  of  the  node. 

list  processing  A  collection  of  functions  and  procedures  implement  the 

usual  list-processing  primitives. 

attributes  For  each  possible  attribute,  there  is  a  function  to  return  the 

value  of  that  attribute  at  a  node,  and  a  procedure  to  store 
a  new  value  for  the  attribute. 

A  complete  listing  of  the  entire  Diana  package  specification  concludes  this 
chapter. 
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with  DSEffiK;  uaa  P8ERTK; 

—  Packaga  USERFK  providaa  tha  following  itama  (aaa  paga  77 )t 


—  aouxca_poaitioni 

—  ayMsol_rapi 

—  valuat 


oparatori 

ntarioar_rapi 


Oaflnas  aouroa  poaltlon  In  original  sourca  program, 
oaad  for  arror  maaaagaa. 

Rapraaantatlon  of  ldantlflars,  atrlnga  and  Charactara. 
lap lamantat Ion  daflnad. 

Glvaa  valua  of  an  axpraaaion. 

Can  lndlcata  that  no  valua  la  coaputad 
EnuaM ration  typo  for  all  oparatora. 

Rapraaantatlon  of  nuaarlc  lltarala. 

Rapraaantatlon  of  ooaaMnta  from  aourca  program. 


pmrlraga  Diana  la 

typa  tree  la  prlvmta; 
typa  seq_type  la  prlvmta; 
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TNOOB^NMtE  is 
deabort, 
deaddtess, 
deali, 

dealtemative_s , 

dearray, 

deattr_id, 

debinary, 

decase, 

<in_cosp_id, 
decoep_unit, 
deeondLentry , 
decoast  rained , 
dedeci_s, 

dedeferred_constant 
dedscrmt_aggregate , 
dedscr*t_var_  a , 
deentry_cali, 
deenue  literals , 
deexit, 
defloat, 
dn_formaX_fix9d , 
dn_ function, 
degeneric, 
degener  ic_paraav.s , 
deif. 
deieop. 
dn_ index, 
de  instantiation , 
deiterat  ioeid . 

deloop, 

demsebership, 

denaasdLsta, 

drv_not_in, 

dn_null_atm, 

dn_nuseric_literal , 

dn_out, 

dn_j>acXage_decl , 

dn_paraaua*soc_8 , 

depragsa, 

dn__private , 

deprocedure, 

deralse, 

dn_reoord_rep , 

de  reverse, 

dn_select_clau»e_s , 

dn_»lice, 

destub, 

desubtype, 

detasKJsody, 

dn_tasK_spec, 

diutype, 

deuniversal_integer 
dn_ueed_bltn_id , 
dn_uaed_nase_id , 
dn_var, 

dn_variant_part , 
dA_while, 

)» 


deaccept, 

disaggregate, 

dn_al locator, 

dn_and_then, 

deassign, 

deattribute, 

deblock, 

deehoice_s, 

dn_coop_rep, 

decompilation, 

dn_conet_id, 

decontext, 

dn_def_Char, 

.  dn^delay, 
dn_dscx«t_id, 
dn_d»crt_range_s , 
dn_antry_id, 
dn_except ion , 
dn_wq?_« , 
defor, 

dn_f ormal_f loat , 

dn_functiorv_call , 

dn_9«ner ic_aa8oc_8 , 

dn_goto, 

dn_in, 

deieout, 

dn_ indexed, 

deinteger, 

dt\_label_id, 

del_prlvate, 

dn_name_8, 

drunamed_stBuid, 

dr\_nulX_acces8 , 

denumber, 

deor_else, 

dn_out_id, 

dn_package_id , 

Separate*, 

dnjpragma^id, 

deprivat*_type_id , 

dn_procedure_call, 

drv_range, 

dtv.ee  name, 

deselect, 

deselected, 

dnstars, 

dn_eubprogra*_body , 

dn_eubtype_id, 

detasklbody_id, 

determinate, 

detype_id, 

,  dn_univereal_real, 
div.used_Mtrv.op , 
deused_ob  ject^id , 
devar_id, 
devariant_s , 
dewith 


deaccess, 

dealignsent, 

dealternative, 

dn_argunerrt_id, 

dn_assoc, 

deattribute_call , 

debox, 

decode, 

decoaip_rep_8 , 

decond_clause , 

deconstant, 

deconversion, 

dedef_op, 

dederived, 

dedscr*t_var , 

deentry, 

deenueuid, 

deexceptioeid, 

defined, 

defoneaO^dscrt , 

deformal^integer , 

defunctloeid, 

deg«neric_id , 

deid_s, 

deieid, 

deieout_id, 

deinner_  record, 

deitees, 

de  labeled, 

del_private_type_id, 

denamed, 

denojJe  fault , 

denull_cc*ap, 

denu»ber_id, 

deothers, 

dnjacJcageJbody, 

depacJcage_spec , 

depsrentheeized, 

depnqMvs, 

deproc_id, 

dequalified, 

derecord, 

dereturn, 

de8«lect_clause, 

deeieple.rep, 

deetring_literal, 

desubprogreedecl, 

desubunit, 

detaelv_decl, 

detia»sd_entry, 

deunivereai_fixed, 

deuse, 

deused_char, 

deused-op, 

devariant, 

devoid. 
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—  Tree  constructors . 

function  MAKE  (ct  in  NODE_NAME)  return  TREE; 

procedure  destroy  ( ti  in  tree); 

function  KIND  (tt  in  TREE)  return  NOOB_namE; 

—  Tree  traversers  from  the  Ada  formal  Definition. 


type  arxties  is  (nullary,  unary,  binary,  ternary,  arbitrary); 

function  ARITY  (tt  in  TREE)  return  ARZTZES; 

function  S0N1  (ti  in  TREE)  return  TREE; 

procedure  S0N1  (tt  in  out  TREE;  vt  in  TREE); 

function  SON2  (tt  in  TREE)  return  TRKB; 

procedure  S0M2  (tt  in  out  TREE;  vt  in  TREE); 

function  SONS  (ti  in  TREE)  return  TREE; 

procedure  SON3  (tt  in  out  TREE;  vt  in  TREE); 


—  Handling  of  list  constructs . 

function  HEAD  (It  in  SBQ_TYPE) 
function  TAIL  (It  in  SEQ_TXPE) 
function  MAKE 

function  ISJMPTY  (It  in  SEQ_TYPE) 
function  INSERT  (It  in  out  SEQJWPE; 

it  in  TREE) 

function  APPEND  (It  In  out  SEP  TYPE; 

it  in  TREE) 


return  TREE;  —  LISP  CAR 

return  SEQ_TYPE;  —  LISP  CDR 
return  SEQJTCPE; 

—  return  empty  list 

return  BOOLEAN; 

return  seq_txpe; 

—  inserts  i  at  start  of  1 

return  SEfiJTYPE; 

—  inserts  i  at  end  of  1 
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—  Handling  of  LIST  attribute  of  list  constructs. 

procedure  LIST  ( ti  in  out  TREE;  vt  la  SEQ.TYPE); 
function  LIST  ( t *  in  TREE)  return  SEQ_T»E; 

—  aggregate  has  Seq  Of 

—  alternative.,*  has  Seq  Of 

—  choice_*  has  Seq  Of 

—  compilation  has  Seq  Of 

—  coep.rep.s  has  Seq  Of 

—  context  has  Seq  Of 

—  decide  has  Seq  Of 

—  dscrnt_aggregate  has  Seq  Of 

—  decrt_range_s  has  Seq  Of 

—  enun_llteralws  has  Seq  Of 

—  exp_s  has  Seq  Of 

—  generic.assoc.*  has  Seq  of 

—  generic_paran_s  has  Seq  Of 

—  id_s  has  Seq  Of 

—  If  has  Seq  Of 


—  inner_recoxd 

—  ite*  s 


—  paraat.assoc_s 

—  parasL.s 

—  pragna_ld 

—  pragma.* 

—  record 

—  *e lect_c lause_ i 


—  use 

—  variant_s 

—  var.s 

—  with 


has  Seq  Of 
has  Seq  Of 
has  Seq  Of 
has  Seq  Of 
has  Seq  Of 
has  Seq  Of 
has  Seq  Of 
has  Seq  Of 
has  Seq  Of 
has  Seq  Of 
has  Seq  of 
has  Seq  Of 
has  Seq  Of 
has  seq  Of 
has  Seq  Of 
has  Seq  Of 
has  Seq  Of 
has  Seq  Of 
has  Seq  of 
has  Seq  Of 
has  Seq  Of 
has  Seq  Of 
has  Seq  Of 
has  Seq  of 
has  Seq  Of 
has  Seq  Of 
has  Seq  Of 
has  Seq  Of 


GOMP_ASSOC 

AI/TERNATIVE 

CHOICE 

OOMP_UNIT 

COMPARER 

COHTEXrjEUat 

decl 

COMP.ASSOC 

DSCRT.RANGE 

EMUH.UTEKM. 

EXP 

GENERIC. ASSOC 
GENERIC.PARAM 
ID 

COND.CLAUSE 

COMP 

ITEM 

NAME 

PARAKJASSOC 

PARAM 


PRAGMA 

COMP 

SELECT.CLAUSE 

STM 

NAME 

VARIANT 

VAR 

NAME 


Structural  Attributes. 


procedure  as  .actual 
function  AS .ACTUAL 
procedure  AS .ALIGNMENT 
function  AS  .ALIGNMENT 
procedure  A3 JU/TERNATIVE.S 
function  A3_ALTERNATIVE_S 


AS.B INAKY.OP 
AS_BINAKY_OP 
AS_HDOCX_STUB 
AS JLOCX.STOB 


AS_CHOICE_S 

AS_CHDICE_S 


AS_CCMP_REP_3 

A3_CGMP_REP_3 

AS.CONSTRAIMED 

AS_COMSTRAINED 

AS_COMSTRAINT 

AS.CCMSTRAINT 

AS.COMTEXT 

AS.COMTEXT 


(ti  la  out  TREE;  vi 
(tt  In  TREE)  return 
(ti  in  out  TREE;  vi 
( tt  In  TREE)  return 
( tt  in  out  TREE;  vt 
(ti  in  TREE)  return 

(ti  la  out  TREE;  vi 
( ti  in  TREE)  return 
(ti  in  out  TREE;  Vi 
(tt  in  TREE)  return 


(ti  in  out  TREE;  vt 
(t>  in  TREE)  return 


_  —  variant 

(ti  in  out  TREE;  vt  in  TREE); 

(tt  in  TREE)  return  TREE  ;  —  record_rep 
(ti  in  out  TREE;  vi  in  TREE); 

(tt  in  TREE)  return  TREE  ;  —  access  I  derived 

_  —  array  I  subtype 

(ti  in  out  TREE;  vt  in  TREE); 

(tt  in  TREE)  return  TREE  ; —  constrained 
{ ti  in  out  TREE;  vt  in  TREE); 

(ti  in  TREE)  return  TREE  ;  —  ooep.unit 


in  THEE); 

TREE  |  —  assoc 
in  TREE); 

TREE  ;  —  record.rep 
in  TREE); 

TREE  ;  —  case 
-—block 
in  TREE); 

TREE  ;  —  binary 
in  TREE); 

TREE  ;  —  packnge_body  I 

—  taskjbody  | 

—  subprogranjaody 
in  TREE); 

TREE  ;  —  alternative  I 
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procedure  as_peci4_s  (ti 

function  A3_deci*_s  (ti 

prooadun  as_deci<_si  (t> 

function  as _DECi(_3l  (ti 

procedure  as_decp_S2  (ti 

fiaction  as_deci4_32  (ti 

pxooaduza  AS.DESIGNATOR  (tl 

function  AS.DESIGMATOR  (tt 


procedure  AS_PESIGMA.TOH.CHAR  (tt 
function  AS_DESIGNATOR_CHAR  (tt 
procedure  AS_PSCRMT_VAR_S  (tt 
function  AS_PSCRMF_VAR_S  (ti 
pxooaduza  as_dscrtjrange  (tt 
function  AS  _DSCRT_RANGE  (tt 

pxooaduza  as.dscrt.range.s  (tt 

function  AS  _DSCRT_RANGE_S  ( t l 
pxooaduza  AS_DSCRT.RANGE.VO I D  (tl 
function  AS_DSCRT_RAMGEL.VOIO  (tt 
pxooaduza  as_exception_def  (tt 
function  AS_EXCEPTION_PEF  ( 1 1 
pxooaduza  ASJEXP  (tt 
function  ASJEXP  (tt 


procedure 

ASJEXP1 

(tt 

function 

ASJEXP1 

(tt 

pcooodura 

ASLJEXP2 

(tt 

function 

AS_EXP2 

(tt 

:  AS_ZXP_C0N STRAINED 

(tt 

TREE); 

function 

AS.EXP .CONSTRAINED 

(tt 

procedure  AS.EXP.S 

(tt 

function 

AS.EXP.S 

(ti 

pcooodura 

i  AS  J3CP.VOID 

(tl 

function 

AS_EXP_V0ID 

(ti 

In  out  TREE;  Vt  In  TREE)) 

in  TREE)  zutuzn  TREE  ;  —  task_spec 

In  out  TREE;  vt  In  TREE); 

In  TREE)  return  TREE  >  —  package_apec 
la  out  TREE;  Vt  In  TREE); 

In  TREE)  zatuzn  TREE  )  —  p&dcaga.spac 

in  out  TREE;  Tt  la  TREE); 

la  TREE)  zatuzn  TREE  ;  —  •ubprograoOxxiy 

—  aubpzogran.dacl 

_  —  aaaoc  I  generic 

In  out  TREE;  Vt  in  TREE); 

In  TREE)  zatuzn  TREE  ; —  salectad 
in  out  TREE;  vt  In  TREE); 
in  TREE)  zatuzn  TREE  ; —  type 
In  out  TREE;  v;  In  TREE); 

In  TREE)  zatuzn  TREE  ;  —  for  I  cavazaa 

_  —-alien 

in  out  TREE;  Vt  in  TREE); 

in  TREE)  return  TREE  ;  —  array 

In  out  TREE;  vt  In  TREE); 

in  TREE)  return  TREE  ;  —  entry 

in  out  TREE;  vt  In  TREE); 

in  TREE)  zatuzn  TREE  ; —  exception 

in  out  TREE;  vt  in  TREE); 

In  TREE)  return  TREE  ;  —  delay  I  cane 

—  fixed  I  float 

—  membership  I  while 

—  addzaaa  I  assign 

—  coda  I  conversion 

—  named  I  number 

—  qualified 

—  aitnple_rsp 

—  unary  I  caaf>_xep 

—  parenthesized 
In  out  TREE;  vt  in  TREE); 

In  TREE)  zatuzn  TREE  ;  —  binary  I  range 
In  OUt  TREE;  Vt  in  TREE); 

In  TREE)  zatuzn  TREE  ;  —  range 

_  —  binary 

In  out  TREE;  vt  In 

In  TREE)  return  TREE  ;  —  allocator 
In  out  TREE;  vt  In  TREE); 
in  TREE)  zatuzn  TREE  ;  —  indexed 

_  —  attribute.call 

In  out  TREE;  vt  in  TREE); 
in  TREE)  return  TREE  ;  —  return 

—  cond .clause 

—  In  I  irv_out  I  exit 

—  out  I  record_rep 
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procedure 

ASjOEMERZC _A330C_S 

(tl 

la 

function 

AS_GENERIC_ASSOC_3 

(tl 

in 

procedure 

AS.GENERIC.HEADER 

(tl 

la 

function 

AS  .GENERI C.HEADER 

(t: 

in 

procedure 

AS_GENERIC_PARAK_S 

(ti 

in 

function 

AS_GENERIC_PARAH_3 

( ti 

in 

procedure  AS .HEADER 

( t* 

in 

function 

ASJ3EADER 

(ti 

in 

pBoamam 

AS_ID 

(ti 

la 

function 

AS_ID 

(ti 

la 

procedure  as  xd_s 

(ti 

In 

function  as_id_s 

(ti 

in 

pcooadurt 

A3_ITEH_S 

(ti 

in 

function 

AS_1TEK_S 

(tl 

in 

procedure  AS.ITERATION 

(tl 

in 

function 

AS  ITERATION 

(tl 

in 

procedure 

AS  .MEMBERSHIP  OP 

(tl 

in 

function 

AS  .MEMBERSHIP  OP 

(tl 

la 

-procedure 

function 

ASJIAME 

AS  _NAKE 

(tl 

(ti 

in 

in 

out  TREE)  V:  la  TREE) j 

TREE)  return  TREE  j  —  instantiation 

out  TREE;  v>  la  TREE); 

TREE)  return  TREE  ;  —  generic 
out  TREE;  Vi  la  TREE); 

TREE)  return  TREE  ;  —  generic 
out  TREE;  vt  la  TREE); 

TREE)  return  TREE  ;  —  subprogranjbody 

_  —  subprograe_decl 

out  TREE;  vt  in  TREE); 

TREE)  return  TREE  ;  —  for  I  attribute 

—  labeled  I  reverse 

—  naaed_sta 

—  padraac  body 

—  package .dec 1 

—  subtype 

—  task  J»dy 

—  variant  .part 

—  type  I  taek.decl 

—  pragim 

out  TREE;  Vt  la  TREE); 

TREE)  return  TREE  ;  —  exception 

—  number  I  constant 

—  la  I  in_out 

_  —  out  I  var 

out  TREE;  VI  in  TREE); 

TREE)  return  TREE  ;  —  block 
OUt  TREE;  Vi  la  TREE); 

TREE)  return  TREE  ;  —  loop 
out  TREE;  VI  la  TREE); 

TREE)  return  TREE  ;  —  membership 
OUt  TREE;  vt  In  TREE); 

TREE)  return  TREE  ;  —  accept  I  address 

—  procedure _call 

—  all  I  conf>_rep 

—  constrained 

—  indexed 

—  instantiation 

—  goto  I  index 

—  qualified 

—  selected 

—  rename  I  slice 

—  variant  _pa_rt 

—  attribute_call 

—  entry  _call 

—  record  _rep 

—  allocator 

—  assign 

—  attribute  I  code 

—  conversion 

—  function_call 

—  slapls_rep 

—  subunit 
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procedure  as_name_s 
function  AS_NAME_S 

procedure  AS JOME_VOID 
function  AS_NAME_VOID 
procedure  AS_OBJECT_DEP 
Amotion  AS_OBJECT_DEF 
procedure  AS _PACXAGE_DEP 
function  AS  _PACKAGZ_DEF 
procedure  AS _parah_ASSOC_s 
function  AS JPARAH_ASSOC_S 


procedure  AS JPARAK.S 
function  ASJPASAMLS 


procedure  AS ^praoia^s 
Amotion  AS_J>RAO«A_S 
procedure  AS_KANGE 
Amotion  AS.RANGE 

procedure  AS_RANGZLVOID 
function  AS _RANGE_VOID 
procedure  AS_RECORD 
function  AS_RECORD 

procedure  as_select_clause_s 

function  AS_SELECT_CLAUSE_S 
procedure  as.stm 
function  AS_STM 

procedure  AS_ST*_S 
Amotion  AS_STK_S 


procedure  AS_STH_S1 
Amotion  as_stk.si 

procedure  AS_STK_S2 
function  AS.S1K.S2 

procedure  as.subprograhjdef 

function  AS.SUBPR0GRAKJ3EF 
procedure  AS_SUBUNIT_B0DY 
Amotion  AS_SOBUNIT_BODY 
procedure  ASJEASKJDEF 
Amotion  AS.TASKJ3C7 
procedure  A3_TYPK.RANGE 
Amotion  AS_TYPE_RANGSE 
procedure  A3_type_spec 
Amotion  AS_T»K-SPEC 


procedure  AS_OWXT_BODY 
Amotion  AS_ONIT_BODY 

procedure  as_variant_s 
function  AS_VARIAHT_S 


(ti  in  out  TREE;  Vi  in  TREE); 

(tt  in  TREE)  return  TREE  ;  —  abort 

—  with  I  use 

(tt  in  out  TREE;  vi  in  TREE); 

(tt  In  TREE)  return  TREE  ;  —  raise  I  exit 
(tt  In  out  TREE;  Vt  In  TREE); 

(tt  in  TREE)  return  TREE  ;  —  constant  I  var 
(tt  In  out  TREE;  Vt  in  TREE); 

(ti  in  TREE)  return  TREE; —  package.decl 
(tt  in  out  TREE;  vt  In  TREE); 

(tt  in  TREE)  return  TREE  ;  —  pr ocedure_cal 1 

—  enfcry.call 

—  pragma 

—  Amctlon_call 
(ti  In  out  TREE;  vt  in  TREE); 

(tt  in  TREE)  return  TREE  ;  —  procedure 

—  function 

—  entry  I  accept 
(tt  in  out  TREE;  vt  in  TREE); 

(tt  in  TREE)  return  TREE  ;  —  coup_unit 
(tt  in  out  TREE;  Vt  in  TREE); 

(ti  in  TREE)  return  TREE  ;  —  integer 

—  cout>_rep 

(tt  in  out  TREE;  vt  in  TREE); 

(tt  in  TREE)  return  TREE  ;  —  fixed  I  float 
(tt  in  out  TREE;  vt  in  TREE); 

(tt  in  TREE)  return  TREE  ;  —  variant 
(tt  in  out  TREE;  vt  in  TREE); 

(tt  in  TREE)  return  TREE  ;  —  select 
(tt  in  out  TREE;  Vt  In  TREE); 

(tt  in  TREE)  return  TREE  ;  —  labeled 

—  named _stm 

(ti  in  out  TREE;  vt  in  TREE); 

(tt  in  TREE)  return  tree  ;  —  alternative 

—  cond.clause 

—  loop  I  select 

—  accept  I  block 
(tt  in  out  TREE;  vt  in  TREE); 

(tt  la  TREE)  return  TREE  ;  —  cond_entry 

—  tinted  _entry 

( 1 1  in  out  TREE;  vt  In  TREE); 

(t:  in  TREE)  return  TREE  ;  —  cond_entry 

_  —  timed.entry 

(ti  in  out  TREE;  vt  in  TREE); 

( 1 1  in  TREE)  return  TREE  ;  —  subprogrant_decl 
(tt  in  out  TREE;  vt  in  TREE); 

(tt  in  TREE)  return  TREE  ; —  subunit 
(tt  in  out  TREE;  vt  in  TREE); 

(t;  in  TREE)  return  TREE  ;  —  tas*_decl 
(tt  in  out  TREE;  vt  in  TREE); 

(tt  In  TREE)  return  TREE  ; —  membership 
(tt  in  out  TREE;  vt  in  TREE); 

(ti  in  TREE)  return  TREE  ;  —  constant  I  in 

—  ±n_out  I  out 

—  var 

_  —  type 

( t i  in  out  TREE;  Vt  in  TREE); 

(ti  in  TREE)  return  TREE  ;  —  coop.unit 
(tt  in  out  TREE;  vt  in  TREE); 

(tt  in  TREE)  return  TREE  ;  —  variant_part 
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—  Lexical  Attributes. 


procedure 

LX_CO*®tENTS 

(fcl 

function 

LX_COMMENTS 

(tl 

procedure 

LX_DEFAULT 

(tl 

function 

LX_DEFALfLT 

(t« 

procedure 

LX_NUMREP 

(tl 

function 

LX_NUMREP 

(tl 

procedure 

LX_PREFIX 

(tl 

function 

LX_PREFIX 

(tl 

ptoosdure 

LX_SRCPOS 

(tl 

function 

UC_SRCPOS 

(tl 

procedure 

LX_SVMREP 

(tl 

function 

LX_SYMREP 

(tl 

in  out  TREE;  vi  coranents); 
in  TREE)  return  coranents  ; 
in  out  TREE)  vi  Boolean)i 
in  TREE)  return  Boolean; 
in  out  TREE;  vs  number_rep ) ; 
in  TREE)  return  number_rep  > 
in  out  TREE;  vt  Boolean); 
in  TREE)  return  Boolean; 
in  out  TREE;  vi  source _posf hi on); 
in  TREE)  return  source ^position  ; 
in  out  TREE;  vt  symbol_rep ); 
in  TREE)  return  symbol_rep  ; 


—  Seeantic  Attributes . 


procedure 

function 

procedure 

Auction 


function 

procedure 

function 

procedure 


function 


TREE); 

function 

procedure 

function 


function 

proceduxs 

function 


function 

fUnctLoo* 


function 


Auction 

function 


sm_actual_delta 

(tl 

in 

out  TREE; 

vi  Float); 

sx_actual_dewa 

(tl 

in 

TREE) 

return  Float; 

SMJtDDRESS 

(tl 

in 

out  TREE; 

vi  in  TREE); 

—  Vi  EXP  VOID 

SH_ADORESS 

(t: 

in 

TREE) 

return  TREE  ; 

—  returns  EXP_VOID 

SH_BASE_TYPE 

(tl 

in 

out  TREE; 

vt  in  TREE); 

—  vt  TYPE  SPEC 

SH_BASE_TYPE 

(tl 

in 

TREE) 

return  TREE  ; 

—  returns  TYPEJSPEC 

sh_bits 

(tl 

in 

out  TREE; 

vi  Integer); 

SH_BITS 

(t: 

in 

TREE) 

return  Integer; 

S«_BODY 

(tl 

in 

out  TREE; 

Vi  in  TREE); 

—  Vi  SOBPJBODYJJESC, 

—  PACK_BODY_PESC, 

—  BLOCK  STUBJVOID 

SH_BODY 

(tl 

in 

TREE) 

return  TREE  ; 

—  returns  SUBP_B0DY_PESC, 

—  PACK_BODY_PESC, 

—  BIOCK_STUBJVOID 

SH_COMP_SPEC 

(tl 

in 

out  TREE; 

vi  in 

3K_CCMP_SPEC 

(tl 

SH_CONSTRAINT 

(tl 

SH_CONSTRAINT 

(tl 

SH.CONTROLLED 

(tl 

SHJXNTRDLLED 

(tl 

SKJDECL-S 

(tl 

SH_DECL_S 

(tl 

SHJXFN 

(tl 

:  in 

SK.DEFN 

(tl 

:  in 

SN_DIBCRZMINANTS 

(tl 

SH_DISCRIMXNANTS 

(tl 

SN_EXCEPTION_PEF 

(tl 

SN_EXCEPTION_DEF 

(tl 

SN_EXP_TYPE 

(tl 

SN_EXP_TYPE 

(tl 

SK_FIRST 

(tl 

SH-FIRST 

(tl 

in  TREE)  return  tree  ; 
in  out  TREE;  vt  in  TREE); 

_  —  Vi  CONSTRAINT 

in  TREE)  return  TREE  ; 

—  returns  CONSTRAINT 
in  out  TREE;  vi  Boolean); 
in  TREE)  return  Boolean  ; 
in  out  TREE;  vi  in  TREE);  —  vi  DECL_S 
in  TREE)  return  TREE  ;  —  returns  DECL_S 

out  TREE;  vi  in  TREE); 

—  Vi  DEF_OCCURRE»CE 

TREE)  return  TREE  ; 

_  —  returns  DEP_occurremce 

in  out  TREE;  Vi  in  TREE);  —  vi  VAH_S 

In  TREE)  return  TREE  ;  —  returns  VAR_S 

in  out  TREE;  vi  in  TREE); 

_  —  V»  EXCEPTXONJDEF 

in  TREE)  return  TREE  ; 

_  —  returns  EXC£PTION_DET 

in  out  TREE;  vi  in  TREE);  —  vi  TYPKJ5PEC 
in  TREE)  return  TREE  ;  —  returns  TYPE_SFEC 

in  out  TREE;  Vt  in  TREE);  —  Vi  DEF_OCCURR 
in  TREE)  return  TREE;  —  returns  DEF_OCCOKR 
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procedure  SH_GENERICJPARAH_S( 1 1  in  out  TREE)  vt  in  TREE)) 

—  V)  GENERXCLPARML.S 

function  SK_GENERIC_PARAK_S( 1 1  in  TREE)  return  TREE) 

—  return*  G£NERIC_PARAM_S 

procedure  SK_INIT_EXP  (tt  in  out  TREE)  v:  in  TREE))  —  vt  EXPJVOID 

function  SK_INIT_EXP  (tt  in  TREE)  return  TREE  >  —  return*  EXP_VDID 

procedure  SH_IOCATION  (t:  in  out  TREE)  vt  in  TREE))  —  vt  LOCATION 

function  SM_LOCATION  (ti  in  TREE)  return  TREE  ;  —  return*  LOCATION 

procedure  SMLNORMALIZEDJPARAMJS  (ttTREE)  vt  in  TREE))  —  vt  EX?_S 

function  SM_NORMALI ZED_PARAM_S  (tt  in  TREE)  return  TREE  ;  —  return*  EXpZs 
procedure  SH_OBJJDEF  (ti  in  out  TREE)  vt  in  TREE))  —  vt  OBJECT JDEF 

function  SH_OBJ_DEP  ( ti  in  TREE)  return  TREE  j  —  return*  OBJECT JDEP 

procedure  SH_OBJ_TYPE  (tt  in  out  TREE)  vt  in  TREE))  —  vt  TYPEJSPEC 

function  SH_OBJ_TYPE  (tt  in  TREE)  return  TREE  >  —  return*  TYPE_SPEC 

procedure  SH_OPERATOR  (tt  in  out  TREE)  vt  operator)) 

function  SH_OPERATOR  (tt  in  TREE)  return  operator  j 

procedure  SH_PACKING  (tt  in  out  TREE)  vt  Boolean)) 

function  SHJPACXXNG  (tt  in  TREE)  return  Boolean  ; 

procedure  SNJPOS  (tt  in  out  TREE)  vt  Integer)) 

function  SH_POS  (tt  in  TREE)  return  Integer  ; 

procedure  SH_REP  (tt  in  out  TREE)  vt  Integer)) 

function  SK_REP  (tt  in  TREE)  return  Integer  ; 

procedure  SM_SIZE  (tt  in  out  TREE)  vt  in  TREE))  —  vt  EXP_VOID 

function  SH_SIZE  (tt  in  TREE)  return  TREE  ;  —  returns  EXP  VOID 

procedure  SH_SPEC  (ti  in  out  TREE)  vt  in  TREE)) 

—  Vt  HEADER 
—  GENERIC  ^HEADER, 

-  —  piycx  spec 

function  SH_S?EC  (ttTREE)  return  TREE  t  —  returns  HEADER 

—  GENERIC  ^HEADER, 

—  PACK  SPEC 

procedure  SMJ5TM  (tt  in  out  TREE)  vt  in  TREE);  —  “  v:  STM,  LOOP 

function  SH_STM  (tt  in  TREE)  return  TREE  >  —  return*  STM,  LOOP 

procedure  SH_STORAGE_SIZE  (tt  in  out  TREE)  Vt  in  TREE))  —  Vt  EXPJVOID 
function  SM_STORAGE_SIZE  (tt  in  TREE)  return  TREE  ;  —  returns  EXP_VOID 

procedure  SH_STUB  (tt  in  out  TREE)  vt  in  TREE)) 

function  SH_STUB  (tt  in  TREE )  return  TREE  ; 

procedure  SM_TYPE_SPEC  (tt  in  out  TREE)  vt  in  TREE))  —  vt  TYPR_SFEC 

function  sh_tvpe_spec  (tt  in  TREE)  return  tree  ;  —  returns  TYPEJSPEC 

procedure  sh_type_strdct  (tt  in  out  TREE)  vt  in  TREE))  —  vt  TYPEJSPEC 

function  Sii_TYPE_STKUCT  (ti  in  TREE)  return  TREE  ;  —  return*  TYPEJSPEC 

procedure  SH.VALUE  (tt  in  out  TREE)  vt  value)) 

function  smlvalue  (tt  in  TREE)  return  value  j 


—  Code  Attribute. 

procedure  CD_IMPLJ3IZE  (tt  in  out  TREE)  vt  integer)) 

function  CD_IMPLJ3IZE  (tt  in  TREE)  return  Integer  t 

privets 

—  To  be  filled  in . . . 


end  Diana) 
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CHAPTER  5 

EXTERNAL  REPRESENTATION  OF  DIANA 


This  chapter  describes  how  a  Diana  tree  may  be  represented  In  ASCII  for 
communication  between  different  computing  systems.  The  presentation  Is  infor¬ 
mal:  for  a  detailed  discussion  of  the  Issues  Involved,  see  Chapter  4  of  the  IDL 
Reference  Manual  (9].  Although  any  conforming  Implementation  of  Diana  is 
required  to  be  able  to  map  to  and/or  from  this  external  representation  of  Diana. 
other  Internal  representations  are  permitted.  Indeed,  we  expect  these  latter 
(non-conforming)  representations  to  be  the  preferred  means  of  communication 
between  tools  on  a  single  computing  system.  The  standard  external  form  is 
defined  to  assist  debugging  and  to  allow  communication  between  computing 
systems,  not  as  the  typical  communication  between  t<5ols. 

The  design  of  this  external  representation  was  guided  by  three  principles: 

•  There  must  be  a  relatively  straightforward  way  of  deducing  the  external 
representation  from  the  Diana  specification  of  Chapter  2. 

•  The  external  representation  must  not  unduly  constrain  the  Implemen¬ 
tation  options  outlined  In  Chapter  6. 

•  It  must  be  possible  to  map  between  the  external  representation  and  a 
variety  of  internal  representations  In  a  reasonably  efficient  manner. 

We  expect  that  each  installation  that  wishes  to  communicate  with  others  via  an 
ASCII  representation  of  Diana  will  create  a  reader/writer  utility  to  map  between 
the  external  representation  and  whatever  Internal  representations  are  In  use  at 
the  Installation. 

The  external  representation  is  described  in  Figure  5-1  on  page  146.  It  is 
the  usual  sort  of  recursive  construction.  Note  that  square  brackets  [. ..]  sur¬ 
round  the  attributes  of  a  node  and  angle  brackets  <. . .  >  surround  Items  of  a 
sequence. 

We  illustrate  the  external  representation  using  the  IDL  example  from  Section 
1.4.1.  repeated  here  as  Figure  5-2  on  page  147.  From  this  example,  nodes 
plus.  leaf,  and  tree  might  be  represented  externally  as  follows: 
plus  —  a  node  with  o  attributes 

leaf  C  nam  "*">  arc  representation  _of  source  _poait  I  on  j  —  leaf  for  A 
tree  C  left  leaf  (nans  "A"]j  right  leaf  [nam  "B"]j  op  plus]  —  A  +  B 
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Definition  of  External  Diana 

node  represented  by  the  name  of  Its  type,  followed  by  followed  by 
the  representation  of  its  attributes  (separated  by  semicolons), 
followed  by  *J\  If  there  are  no  attributes,  the  '(  1*  may  be 
omitted. 

attribute  represented  by  the  name  of  the  attribute,  followed  by  the 
representation  of  the  value  of  the  attribute. 

comment  start  with  double  hyphen  (‘ — ') :  terminate  with  the  end  of  the 
line. 


REPRESENTATION  OF  BASIC  TYPES 

Boolean  represented  by  the  tokens  true  and  false. 

Integer  represented  by  a  sequence  of  digits  with  an  optional  sign.  The 
value  is  Interpreted  as  being  a  decimal  Integer. 

Rational  represented  as  a  decimal  or  based  number  (In  the  Ada  sense 
and  using  the  Aoa  syntax) .  or  as  the  quotient  of  two  unsigned 
Integers,  decimal  numbers,  or  based  numbers. 

string  represented  as  the  sequence  of  ASCII  characters  representing 
the  value  of  the  string,  surrounded  by  double  quotes.  Any 
quotes  within  the  string  must  be  doubled.  The  nonprinting  ASCII 
characters  are  represented  as  In  Ada. 

Sequence  represented  by  a  sequence  of  representations  for  Individual 
values  of  the  sequence,  separated  by  spaces,  and  surrounded 
by  angle  brackets  ('<...>'). 

Private  types  are  provided  by  the  structure  definition.  For  our  purposes. 

the  external  representations  of  the  private  types  used  in  Diana  are  provided 

in  a  refinement  of  the  Diana  abstract  structure. 

Spaces  are  not  significant  except  to  separate  tokens. 

Case  distinctions  between  Identifiers  (such  as  node  names)  are  significant. 

as  In  IDL. 


Figure  5-1: 


External  Diana  Form 
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Note  that  no  representation  is  shown  tor  the  value  of  the  attribute  arc.  which  Is 
the  private  type  Source.Positlon:  this  point  is  addressed  further  below.  Note 
also  that,  because  these  examples  show  external  Diana  which  is  expected  to  be 
ASCII  text,  the  usual  typographic  conventions  for  node  names  and  attributes  are 
not  followed  In  them. 


Structure  ExpressionTree  Root  EXP  is 

—  First  we  define  a  private  type. 
Type  Source_Pos it ion ; 


—  Next  we  define  the  notion  of  an  expression,  EXP. 
EXP  i leaf  I  tree  ; 


—  Next  we  define  the  nodes  and  their  attributes. 

tree  ->  opt  OPERATOR,  /efts  EXP,  right :  EXP  ; 

tree  ">  arc-.  Source_Poaition  t 

leaf  ■>  name:  String  t 

leaf  •>  arc:  SourceJPosition  j 


—  Finally  we  define  the  notion  of  an  OPERATOR  as  the 

—  union  of  a  collection  of  nodes »  the  null  ->  productions 

—  are  needed  to  define  the  node  types  since 

—  node  type  name  axe  never  implicitly  defined. 

OPERATOR  : :  -  plus  I  sinus  I  tines  I  divide  » 
plus  ->  ;  sinus  ■>  ;  tines  ->  ;  divide  ■>  > 

End 

Figure  5-2:  Example  ExpreaalonTroo  of  IDL  Notation 


The  external  representation  also  provides  a  means  for  sharing  attribute  values 
between  nodes.  This  fact  does  not  necessarily  imply  that  the  corresponding 
Internal  representation  is  shared;  for  some  attributes,  the  sharing  in  the  external 
representation  can  be  viewed  simply  as  a  technique  for  compressing  space. 


I 


Page  148  /  Section  5 


Diana  Reference  Manual 


However,  any  attribute  value  which  Is  Inherently  shared  Internally 1  must  be 
represented  externally  In  shared  form.  All  of  the  tree-valued  attributes  of  Diana 
fall  In  this  category. 

In  order  for  an  attribute  value  to  be  shared  In  the  external  representation, 
one  occurrence  of  the  value  must  be  labeled  and  all  other  occurrences  must 
refer  to  that  label.  Any  attribute  value  may  be  labeled.  Including  node-valued 
attributes.  The  labeled  occurrence  of  the  value  Is  represented  in  a  normal  way. 
except  that  it  is  preceded  by  a  label  Identifier  and  a  colon  <*:*>.  Each  label 
reference  consists  of  the  label  Identifier  followed  by  a  caret  rather  than 

the  usual  representation  of  the  attribute  value.  A  label  Identifier  is  a  sequence 
of  letters,  digits,  and  Isolated  underscores  starting,  with  a  letter;  case  distinc¬ 
tions  among  the  letters  are  significant.  For  example,  the  tree  for  A+A  could  be 
represented  in  any  one  of  the  following  four  ways  (among  others): 

tree  [  left  leaf  [  name  "A"] »  op  plus;  right  leaf  [  name  "A"  ]  ] 

tree  [  left  leaf  (  nane  yt  "A"  ];  op  plus;  right  leaf  [  naee  y~  ]  ] 
tree  [  left  xtleaf  C  name  NA”1|  op  plus;  right  x~  ] 

tree  C  left  x~;  op  plus;  right  fc:lea£  [  name  "A"  ]  ] 

Additionally,  a  node-valued  attribute  can  be  written  free  standing  without  being 

nested  within  some  other  node.  For  example,  a  fifth  representation  for  the 

preceding  example  is 

tree  [  left  x~;  op  plus;  right  r  J 
x:  leaf  [  name  "A"  ] 

Note  that  In  these  examples  we  have  consistently  avoided  giving  a  represen¬ 
tation  for  the  source  position  attributes.  Recall  that  source  position  Is  a  private 
type  whose  representation  must  be  supplied  as  part  of  the  structure  definition  or 
a  refinement  of  the  structure.  One  way  to  represent  the  source  position  is  to 
use  the  representation  defined  In  the  example  refinement  in  Section  1.4.3  on 
page  28.  repeated  here  for  convenience  in  Figure  5-3  on  page  140.  Using  this 
external  form,  a  source  position  might  be  represented  using  the  node  structure: 

leaf  C  name  "A"; 

arc  source_position 

(  file  "<user>test.aaa”  /  line  3  $  Char  15  ) 

1 


tfM 

•  < 


The  phrase  'Inherently  (hared  Internally1  la  Intentionally  loose.  We  believe  that  the  phrase  oaptures 
essence  of  the  situations  where  It  is  oonvsntent  to  use  therlnq  In  the  entente!  representation.  For 
omplete  Oaousslon  of  this  Issue,  see  the  ICX  deference  Manual. 
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Structure  AnothezTxee  Renaeea  Express ionTree  is 

—  first  the  internal  representation  of  Saurce_Poeltlon 
For  Source  JPoeition  Use  Source  _Packags; 

—  next  the  external  representation  of  Source_Position 

—  is  given  by  a  new  node  type,  source_astemaV_rap 

For  Source _Position  use  External  source_extsrnaXjrsp> 

—  finally,  we  define  the  node  type  souroe_externalv_rep 

source_extemal_rep  »>  file  t  String, 

line  t  Integer, 
char  i  integer t 


End 


Figure  5-3:  Example  AnotherTree  of  IDL 


Alternatively,  a  specification  could  define  the  source  position  to  be  represented 
externally  as  a  string: 

leaf  C  nas»  "A";  arc  "<user>test.ada/l5/3" J 
Each  of  these  particular  external  representations  in  some  sense  contains  the 
same  Information  in  that  either  one  could  be  mapped  to  the  same  internal 
representation  by  the  reader  utility.  Each  Installation  must  establish  conventions 
for  communicating  between  the  reader/writer  utility  and  Its  user-supplied 
packages  to  allow  such  user-supplied  types  to  be  mapped  to  and  from  the 
external  form.  Of  course,  other  representations  for  the  source  position  attribute 
are  possible,  many  containing  quite  different  Information.  A  more  complete 
treatment  of  the  external  representation  of  private  types  may  be  found  in  the  IDL 
Reference  Manual. 

The  refinement  of  the  Diana  structure  defines  the  external  representation  tor 
tour  private  types.  symbol^/ep.  number _rep.  operator,  and  value.  Types 
symbol ^/ep.  and  number op  are  represented  as  strings  externally,  and  operator 
is  represented  by  an  enumeration  type. 

The  type  symbol WP  Is  «  string  that  contains  the  source  representation  of 
identifiers.  The  type  symbol _rop  also  represents  character  literals,  which  are 
distinguished  from  other  Identifiers  by  surrounding  the  character  with  single  quote 
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marks,  as  In  Ada.  An  Implementation  must  decide  how  to  treat  upper  and  lower 
case  characters:  It  can  normalize  the  representations  of  Identifiers  to  use  the 
basic  character  set.  all  lower  case  letters  changed  to  upper  case,  or  It  can 
preserve  the  case  used  In  the  source,  so  that  source  can  be  reconstructed 
accurately. 

The  type  number_jep  Is  a  string  that  has  the  source  representation  of 
numeric  literals.  An  implementation  may  choose  to  normalize  numeric  Jlterala  by 
removing  underscores. 

The  type  operator  Is  represented  by  an  enumeration  type.  In  the  refined 
Diana  specification  a  minimum  enumeration  set  Is  given:  it  may  be  expanded  by 
an  Implementation  to  Include  any  other  built-in  subprograms. 

The  type  value  is  represented  as  an  Integer  or  rational  type  if  a  value  has 
been  computed,  or  with  a  distinguishing  node  for  the  cases  where  the  value  has 
not  yet  been  computed.  A  representation  for  ADA  strings  and  arrays  Is  also 
provided:  a  sequence  of  values. 

A  complete  external  representation  starts  with  an  Indication  of  the  root  node 
of  the  corresponding  structure,  followed  by  a  sequence  of  zero  or  more 
representations  of  nodes.  The  root  Indication  can  be  either  a  label  referencing 
a  node  elsewhere  in  the  external  representation  or  the  root  node  itself.  Since 
the  representation  of  subnodes  can  be  contained  within  the  representation  of  the 
parent  node,  it  is  possible  for  the  entire  external  representation  to  be  given  by 
the  root  (a  compilation  node  In  Diana)  .  It  Is  permissible,  on  the  other  hand,  to 
represent  the  Duma  tree  In  a  flat  form,  where  node-valued  attributes  are  always 
represented  by  labels  referencing  non-nested  representations  of  the  nodes. 

Following  are  two  examples,  both  in  flat  form.  In  each  case  a  short  Ada 
fragment  is  followed  by  the  external  form  of  the  Diana.  Note  that  these  ex¬ 
amples.  like  the  figures  in  Chapter  3.  are  Incomplete  In  that  some  attributes  are 
omitted  for  expository  convenience. 
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—  From  package  STANDARD  (sort  of) 

type  BOOLEAN  Is  (FALSE,  TRUE): 

typ«  integer  Is  range  minjnt  . .  maxjnt; 


PDO: 

type 

(  as_ld  PD1  *  : 
as_var_s  PD2*  : 
as_type_spec  PD3*  1 

PD1: 

typejd 

(  lx_symrep  ‘BOOLEAN*  ; 
sm_type_spec  PD3*  1 

PD2: 

var_s 

(  as_list  <  >  ] 

P03: 

enumjiteral_3 

(  asjist  <  PD4*  P05*  > 
sm_slze  void  ] 

PDA: 

enumjd 

(  lx_symrep  "FALSE*  ; 
sm_ob}_type  PD3  *  : 
sm_rep  0  : 
sm_pos  0  ) 

P05: 

enum_id 

t  lx_symrep  'TRUE*  : 
sm_ob|_type  PD3*  : 
sm_rep  1  : 
sm_pos  1  1 

PDC: 

type 

{  as_ld  PD8*  ; 
as_var_s  PD7*  : 
aa_type_spec  PD9*  ) 

P07: 

var_s 

[  asjist  <  >  1 

PD8:  type_ld 

C  lx_symrep  ’INTEGER-  : 
sm_type_spec  PD9*  1 

PD9:  integer 

f  as.range  PD10* 

sm_type_struct  PD9*  : 
sm_size  void  J 

PD10:  range 

l  as_exp 1  PD1 1  *  : 
as_exp2  PD12*  : 
sm_base_type  PD9*  J 

PD  1 1 :  used_ob|ect_id 

(  lx_symrep  *MIN_INT*  : 
sm_defn  xxx' 
sm_value  xxx * 
sm_exp_type  PD9*  ) 

—  def 

—  def 

for  MINJNT 
for  MINJNT 

P012:  used_ob|ect_ld 

(  lx_symrep  "MAXJNT*  : 
sm_defn  xxx* 
sm.value  xxx* 

--  def 
—  def 

for  MAXJNT 
for  MAXJNT 

sm_exp__type  PD9*  J 


( 
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package  REPORT  la 


function  EQUAL  (  X.  Y  :  integer  )  return  boolean: 


end 

REPORT; 

A01 : 

comp.unit 

(  as_pragma_s  A02‘  ; 
as.context  A03*  : 

as_unlt_body  A04*  1 

A02: 

pragma_s 

(  as_list  <  >  1 

A03: 

context 

t  as.llst  <  >  ] 

A04: 

package.decl 

t  asjd  A05*  : 

as_package_def  A06*  ) 

AOS: 

package_id 

[  lx_symrep  'REPORT*  ; 
sm_spec  AOS*  ; 
sm_body  void  : 

sm_address  void  ] 

AOS: 

package_spec 

t  as_decl_sl  A08*  : 
as_decl_s2  AO  7*  J 

A07: 

as_decl_3 

(  as_list  <  >  ) 

AOS: 

as_decl_s 

(  as_list  <  A09*  >  1 

AOS: 

subprogram_decl 

(  as_designator  A10*  ; 
as_heaaer  All* 
as_subprogram_def  void  ] 

A10: 

function_id 

t  lx_symrep  'EQUAL'  : 
sm_spec  All*  : 

sm_body  void  : 
sm_locatlon  void  1 

All: 

function 

I  aa_param_9  A12*  : 
as_name  A18*  ) 

A12: 

param.s 

C  asjlat  <  A13*  >  1 

A13: 

in 

(  aa_id_s  A14  * 
aa.name  A17* 
aa_exp_vold  void  1 

A14: 

ld_3 

(  aajist  <  A15*  A16*  >  J 

A15: 

ln_ld 

C  lx_symrep  'X'  : 
am_lnit_exp  void  ; 

sm_ob|_type  P09*  J 

A16: 

Injd 

t  lx_aymrep  *Y*  : 
3m_lnit_exp  void  : 

sm_ob|_type  PD9*  J 

A17: 

used_name_id 

(  lx_symrep  'INTEGER'  : 
sm.defn  PD8* 

A18: 

used_name_id 

(  lx_symrep  'BOOLEAN'  : 
3m_defn  POl*  1 

J 
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CHAPTER  6 

IMPLEMENTATION  OPTION8 


One  obvious  Implementation  of  a  compiler  using  the  Diana  intermediate  form  Is 
to  produce  the  complete  Diana  abstract  tree  as  the  result  of  semantic  analysis, 
representing  each  abstract  tree  node  by  a  variant  record  on  a  heap  and  using 
pointers  to  implement  those  attributes  that  reference  other  nodes.  In  some 
applications  such  an  Implementation  may  be  completely  appropriate:  In  others.  It 
may  not.  The  purpose  of  this  chapter  Is  to  Illustrate  some  other  Implementation 
options  that  are  possible.  We  cannot,  of  course,  describe  all  conceivable 
options:  our  goal  is  merely  to  describe  enough  of  them  to  make  the  point  that 
the  obvious  Implementation  la  not  the  only  possible  one. 

At  the  risk  of  repeating  the  point  once  too  often,  we  stress  that  Diana  Is 
representation  Independent.  Possible  Implementations  Include  any  of  the  schemes 
mentioned  below,  many  others,  and  combinations  of  them.  Each  possibility 
makes  good  sense  In  certain  applications  or  for  certain  Implementation  environ¬ 
ments. 

A  Coroutine  Organization:  The  Front  and  Sack  Ends  of  the  compiler  might  be 
organized  in  a  coroutine  manner.  In  which  the  Front  End  produces  a  portion  of 
the  intermediate  form  after  which  the  Back  End  produces  code  for  this  portion 
and  then  discards  the  unneeded  pieces  of  its  input.  In  this  organization  there 
would  never  be  a  Diana  representation  of  the  entire  compilation  unit  at  any  one 
time.  Instead,  only  a  consistent  Diana  subtree  tor  the  portion  being  communi¬ 
cated  Is  needed.  Although  this  type  of  organization  may  limit  the  amount  of 
optimization  that  can  be  done.  It  Is  often  uselul  and  Is  completely  consistent  with 
the  Diana  model.  To  use  this  style  of  compiler  organization,  the  user  needs 
only  to  ensure  that  the  values  of  all  of  the  attributes  for  the  portion  of  the  tree 
being  communicated  are  defined  properly. 

Woe-Tree  Structurma:  Many  simple  compilers  use  a  linear  representation,  such 
as  Polish  postfix,  for  the  Intermediate  form.  Such  a  representation  has  the 
advantage  of  simplifying  certain  tree  traversals,  and  Indeed  may  be  obtained  from 
the  Oiana  tree  by  fust  such  a  traversal.  Such  representations  may  also  have  an 
advantage  In  that  they  are  more  efficient  where  storage  is  limited  or  paging 
overheads  are  high.  Again,  such  representations  are  fully  within  the  spirit  of 
Diana.  Where  Diana  requires  a  (conceptual)  pointer.  It  may  be  replaced  by  an 
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index  into  the  linear  representation. 

DAQ  Representation :  The  structural  attributes  of  Diana  define  a  tree  cor¬ 
responding  to  the  abstract  syntax  of  Ada.  So  long  as  the  processing  algorithms 
do  not  require  distinct  copies  of  Identical  subtrees,  such  subtrees  may  be 
shared  to  save  memory  space.  The  resulting  storage  structure  Is  a  directed 
acyclic  graph,  or  DAQ.  This  observation  Is  especially  important  with  respect  to 
(eaves  of  the  tree  and  to  certain  attribute  values.  Typically,  for  example,  about 
half  the  nodes  In  a  tree  are  leaves;  thus,  substantial  space  can  be  saved  by 
using  a  single  instance  of  a  used_name_id  node  to  represent  all  of  its  logical 
occurrences  in  the  Diana  tree.  Similarly,  occurrences  of  the  attributes  that 
represent  literal  values  and  the  string  name  of  Identifiers  In  the  program  can  be 
pooled. 

Attributes  Outside  the  Nodes:  There  Is  no  need  for  the  attributes  of  a  node  to 
be  stored  contiguously.  As  there  are  many  variations  on  this  theme,  we 

illustrate  just  one  here.  Suppose  that  the  general  storage  representation  to  be 
used  involves  storing  each  node  as  a  record  in  the  heap  and  using  pointers  to 
encode  the  structural  attributes.  Because  there  are  a  number  of  different 
attributes  associated  with  each  node  type,  one  may  not  wish  to  store  these 
attributes  directly  In  the  records  representing  the  nodes.  Instead,  one  might 
define  a  number  of  vectors  (of  records)  where  the  records  In  each  vector  are 
tailored  to  the  various  groupings  of  attribute  types  In  Diana  nodes.  Using  this 
scheme,  the  nodes  themselves  need  contain  only  an  Index  Into  the  relevant 
vector.  Such  a  scheme  has  the  advantage  of  making  nodes  of  uniform  size  as 
well  as  facilitating  the  sharing  of  identical  sets  of  attribute  values. 

General  Set  of  Attributes:  All  nodes  can  be  Implemented  with  a  general  set  of 
attributes,  and  all  other  attributes  could  be  kept  outside  the  nodes.  A  Boolean¬ 
valued  attribute  in  the  node  can  then  be  used  to  Indicate  that  an  attribute  outside 
the  node  exists.  This  method  is  useful  for  attributes  that  may  be  on  several 
nodes  but  is  generally  void  (such  as  fx_commenfa) . 

Nodes  Inside  Other  Nodes:  Although  an  attribute  of  a  node  may  reference 
another  node,  there  is  no  Implication  that  a  pointer  Is  required:  the  referenced 
node  may  be  directly  Included  in  the  storage  structure  of  the  outer  node  so  long 
as  the  processing  permits  this.  This  approach  Is  especially  Important  where  the 
referenced  node  has  no  attributes.  For  example,  the  binary  node  of  Diana  has 
an  attribute  called  aa^binary^op  which  references  one  of  a  number  of  possible 
nodes— all  of  which  have  no  attributes.  In  effect,  this  attribute's  value  Is  an 
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enumeration  type  and  can  be  implemented  as  a  small  Integer  stored  in  the 
binary  node's  storage  area. 

Coploa  of  Attrlbuto  Valuoa:  An  Implementation  may  choose  to  copy  the  value 
of  an  attribute,  o.g. .  If  the  attribute  value  Is  stored  In  another  compilation  unit. 
The  implementation  must,  of  course,  preserve  the  semantics  of  the  equality  test 
and  assignment  operations  for  attribute  values,  as  discussed  in  Section  3.  9. 

Soparato  Symbol  Tattoo:  The  collection  of  nodes  types  which  constitute 
DEF_OCCURRENCEs  are  effectively  a  symbol  table.  This  presentation  discusses 
such  nodes  as  if  they  were  part  of  the  tree,  but  an  Implementation  may  elect  to 
collect  these  nodes  together  into  a  compact  structure,  physically  separate  from 
the  tree. 
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THE  PREDEFINED  ENVIRONMENT 


The  semantics  of  Ada  provide  that  an  Ada  program  may  reference  certain 
entitles  that  are  not  defined  within  the  program  Itself.  There  are  four  cases: 

universal  types  These  cannot  be  mentioned  by  the  programmer  but  are 

referenced  only  implicitly.  For  example.  they  are 
referenced  in  describing  the  type  of  a  number,  or  in 
describing  the  result  of  certain  Ada  attributes. 

predefined  language  environment 

This  is  essentially  the  package  STANDARD. 

attributes  These  Include  both  those  predefined  by  Ada  as  well  as 

those  defined  by  the  implementation. 

pragmas  These  include  both  those  predefined  by  Ada  as  well  as 

those  defined  by  the  Implementation. 

In  the  following  four  sections  of  this  appendix  we  describe  how  the  Diana  form  for 
each  of  these  Is  derived. 


1.1.  Universal  Types 

The  notion  of  universal  types  Is  used  in  Ada  to  associate  a  type  with  a 
number  declaration  and  to  define  the  result  type  of  certain  attributes.  To 

represent  these  notions.  Oiana  extends  the  class  TYPE_SPEC  by  three  nodes: 
TVf*e_SPEC  : :  *  uniwruMntvgw  I 

untwrMl_rMl  | 
uniwrMl_ft»d  ; 

These  nodes,  which  have  no  attributes,  can  be  referenced  only  by  semantic 
attributes  of  a  program:  they  never  appear  directly  in  the  tree.  The  type 
untversal_reai  covers  both  fixed  and  float  types  In  cases  where  they  cannot  be 
distinguished,  as  in  number  declarations. 

1.2.  The  Predefined  Language  Environment 

The  predefined  environment  of  Ada  Is  specified  by  the  package  STANDARD, 
given  In  Appendix  C  of  the  Ada  LRM.  The  Diana  tree  for  It  may  be  obtained  by 
simply  compiling  this  package  with  a  Front  End.  though  the  compilation  must  be 
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done  in  a  special  mode  since  some  attributes  must  be  determined  by  special 
rules.  In  a  few  cases  (such  as  cd_/mp/_s/ae  for  numeric  types),  the  attributes 
must  ba  explicitly  assigned:  they  cannot  be  derived  from  any  further  environment 
Inquiry.  Note  that  this  operation  need  be  done  only  once:  the  Diana  form  can 
then  be  preloaded  into  all  programs  that  process  the  Diana  form  of  Ada. 

Since  the  Front  End  and  Back  End  must  be  able  to  agree  on  the  oporator 
type  (see  Section  3.8.5)  and  the  Front  End  must  be  able  to  communicate  this 
information  to  the  Back  End.  the  two  must  agree  on  how  the  representation  of 
package  STANDARD  is  to  be  augmented  to  Include  this  Information. 

1. 3.  Attributes 

Appendix  A  of  the  Ada  LRM  describes  a  set  of  predefined  language 
attributes:  these  may  be  extended  by  an  implementation,  see  LRM  Section 
4.1.4.  Diana  requires  a  unique  definition  point  for  each  of  these  attribute 
identifiers.  Diana  does  not  define  additional  Information  for  checking  that  at¬ 
tributes  are  used  correctly:  the  design  of  this  information  is  a  choice  for  each 
implementation.  We  also  need  a  string  representation  of  the  attribute  name  (to 
reconstruct  the  source,  for  example) .  The  resulting  structure  looks  like: 

0£F_*O 

*>  lx _syntr+p  :  symbol_r«p; 

The  complete  definition  of  an  ADA  program  requires  nodes  for  all  the  implemen¬ 
tation  supported  attributes;  these  are  easily  constructed.  Using  the  external  form 
of  Oiana  defined  In  Chapter  5.  for  example,  two  of  the  predefined  attribute  nodes 
are: 


afctr_id  [  l*.synrep  "BITS"  ] 
attr_id  [  lx_symrep  "SMALL"  ] 


1.4.  Pragmas 

Appendix  B  of  the  Ada  LRM  lists  the  language-defined  pragmas  for  Ada.  An 
implementation  Is  free  to  expand  this  set  by  defining  additional  pragmas.  Diana 
provides  a  definition  point  for  the  identifiers  needed  to  represent  the  complete  set 
of  pragmas  known  ,o  an  Implementation.  The  Diama  representation  of  these  Is 
similar  to  its  representation  of  attributes  described  above:  in  the  predefined 
environment,  dlana  provides  the  information  necessary  to  Identify  the  pragma 
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names  and  their  names  of  its  arguments.  In  addition,  where  the  possible  values 
of  a  pragma's  arguments  are  named  (e.g. .  for  pragma  UST  the  values  *0N* 
and  ‘OFF*) .  a  defining  occurrence  for  the  names  of  the  values  is  also  provided. 

The  defining  occurrence  for  an  Identifier  used  in  conjunction  with  a  pragma  in 
Diana  has  the  following  structure: 

OEF_ID  pngmajd  I  ARGUMENT  ; 

prsgm«_M  =>  Mjlat  :  S«q  Of  ARGUMENT  ; 

ARGUMENT  :  argunwntjd  ; 

pr*gm«_ld  =>  lx_aymnp  :  aymbol_r*p  ; 

«rgvm*nt_k)  =>  lx_9ymr»p  :  *ymbol_r«p  ; 

A  list  of  argument  names  is  Introduced  for  those  situations  where  multiple 
argument  names  are  possible,  as  for  example  for  the  various  check  names  for 
the  SUPPRESS  pragma.  Note  that  the  list  is  also  used  to  introduce  the  names  of 
the  values  the  pragma's  arguments  may  take. 

As  with  the  attributes,  an  Implementation  must  supply  a  set  of  nodes  for  the 
various  language-defined  and  Implementation-defined  pragmas.  Here  are  two  ex¬ 
amples  In  external  Diana  form: 

pragma id  [  lx_symrep  "LIST";  as_list  <I*1~  L2~> ] 

Uli  argun»nt_id  [  l*_symrep  "ON"  ] 

1.2:  argument_id  [  lx_symrep  "OFF"] 

pragva_id  [  lx_syrarep  "PRIORITY"  ] 

All  checks  concerning  the  correct  use  of  i.  pragma  are  assumed  to  have 
been  done  during  semantic  analysis,  and  performing  these  checks  will  neces¬ 
sarily  require  knowledge  of  the  semantics  the  pragma  that  Diana  cannot  supply. 
The  predefined  environment  merely  provides  the  defining  occurrences  for  the 
identifiers  used. 

For  language-defined  pragmas.  Diana  requires  that  the  pragma  subtree 
represents  a  correct  pragma:  that  Is.  for  each  pragma  the  proper  semantic 
checking  has  been  done.  For  pragmas  not  supported  by  an  implementation 
Oiama  requires  that  the  structure  of  the  pragma  subtree  is  present  and  contains 
the  lexical  information  but  does  not  require  that  the  semantic  attributes  are 
correct.  In  most  cases  this  requirement  means  the  pragma  name  and  argument 
names  are  represented  by  used_name_td  nodes  whose  sm_d»fn  attribute  is  void. 
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There  are  several  situations  where  the  arguments  to  a  pragma  are  types  or 

objects  defined  by  the  user.  The  pragma  node  has  a  structural  attribute  which 

represents  the  list  of  actual  arguments  to  a  particular  pragma;  the  list  In  the 

pragma. Id  corresponds  in  a  sense  to  formal  parameters.  Figure  1-1  shows  the 

tree  for  the  fragment 

type  C  is  acray(l..l0)  of  CHARACTER; 
pragma  PACX(C); 


pragma 


Figure  1-1:  Example  of  a  Pragma 
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THE  ABSTRACT  PARSE  TREE 


Ada's  Formal  Definition  assumes  a  parse  tree  that  is  structurally  quite  similar 
to  the  Diana  tree  described  in  Chapter  2.  This  appendix  shows  the  IDL 
representation  for  this  parse  tree. 

Following  are  the  principal  differences  between  the  parse  tree  and  the  Diana 
tree: 

•  The  parse  tree  has  no  semantic  or  code  attributes. 

•  The  parse  tree  has  apply  nodes  Instead  of  function  call,  procedure 
call,  entry  call,  attribute  call,  indexed,  conversion,  and  slice  nodes. 

IDL  provides  a  means  for  deriving  a  structure  from  a  previously  defined 
structure  by  describing  the  new  structure  in  terms  of  changes  or  edits  to  the  old 
structure.  This  form  of  structure  declaration  has  the  following  basic  form: 

Structure  ne*»_structure  Root  root 

Prow  oldest ructure  Is 

—  "edits"  to  old  structure 

End 

There  are  two  sorts  of  edits:  additions  to  the  original  structure  and  deletions 
from  it.  Additions  are  Indicated  by  simply  Including  the  additions  within  the 
structure  declaration  as  normal  IDL  definitions.  Deletions  are  indicated  by 
clauses  beginning  with  the  keyword  Without,  followed  by  a  list  of  items  to  be 
deleted  from  the  original  structure  in  forming  the  new  one.  Five  kinds  of 
deletions  can  be  made: 

•  Deletion  of  a  particular  element  from  the  right  side  of  a  class  defini¬ 
tion  Is  indicated  by  an  entry  of  the  form 

class.nasw  t  :•  elewnt_nagsa 

Here  an  "element*  can  be  either  a  class  or  a  node.  Here  is  an 
example: 

—  old 

EXP  1 1-  Coo  |  leaf  I  tree 

—  without  clause 

Without  EXP  ti-  leaf 

—  nee 

EXP  t  tm  too  I  tree 

•  Deletion  of  a  particular  attribute  from  the  right  side  of  a  node  defini¬ 
tion  Is  indicated  by  a  line  of  the  form 
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nod* _naa*  •>  attribute_nam 
Here  is  an  example: 

—  old 

tree  ->  left: EXP,  op: OP,  right : EXP 

—  without  clause 

Without  tree  ->  left 

—  new 

tree  •>  optOP,  right: EXP 

•  Deletion  of  an  entire  class  definition  Is  Indicated  by  giving  just  the 

class  name  followed  by  as  in 

POO  it- 

•  Deletion  of  an  entire  node  definition  Is  Indicated  by  giving  just  the 

node  name  followed  by  as  in 

too  -> 

•  Deletion  of  an  attribute  name  Is  Indicated  by  writing 

*  •>  too 

The  attribute  is  thereby  deleted  from  all  nodes  which  named  it. 

Using  this  notation,  we  now  derive  from  Diana  the  structure  ParseTree.  with 
root  COMPILATION. 
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Structure  PsrseTree  Root  COMPILATION  From  Diana  la 

—  PsrseTree  has  APPLY  nodes  Instead  of  function  call,  procedure  cad, 

—  entry  caN,  attribute  call,  Indexed,  conversion,  and  slice  nodes. 

Without 

function  _caH  *», 
prooeduro.cail  *», 
entry  coll  *>, 

«ttribute_caH  *>. 

Indexed  =>, 
siioe  *>, 
conversion  =>  , 


NAME  :  := 
NAME  ::= 
NAME  :  := 
NAME 
EXP  ::s 


attribute_call, 
tunction.call, 
slloe,  ~ 
Indexed, 
conversion, 


STM  :  :*  procedure_ceH, 

STM  :  :=  entry .cauf 

—  additions  for  APPLY 


STM  :  :=  NAME; 

NAME  ::=  apply; 


apply  => 


/x.arcpoa 
/<_comnrent  s 

aa.param_ assoc.s 


;  NAME, 

;  source .position, 

;  comments, 

;  GENERAL  ASSOC  S; 


GENERAL  ASSOC.S  ;  ;*  general  assoc  s; 

generai.aaaoc.s  «>  aa_«af  :  Seq  Of  GENERAL.ASSOC, 

Ix^arcpoa  :  source .position, 

/x.commsnfs  ;  comments, 

GENERAL. ASSOC  ACTUAL  I  RANGE  I  named; 

—  Parse  Tree  has  only  one  kind  of  USEQJD 


Without 

uaed.name.td  =>  , 
uaed_ob|ect_tc'  »>  , 
uasd.numbsr.id  =>, 
uasd.bltnjd  *>, 
USED  10 
U8ED.ID 
U8EO_IO 


—  additions  lor  USEDJD 


USED.® 
uaed.id  *> 


uaed_name_ld, 

uaed_obi«sct_ld, 

uaed.bltn.id; 


uaed.id; 

lx_arcpo» 

fx.commenfs 

ftr_«ymrep 


;  source  .position, 
:  oomments, 

;  symbol.rep; 


—  ParseTree  has  only  one  Mod  of  USED.OP 
Without 


used.op  *>  , 
string  literal  *>  , 


-  jftn.op  =>  , 

DESIGNATOR 
EXP 

—  additions  for  USED.OP 

DESIGNATOR 
d.strtng  *> 


uaad.op, 
string  litoral: 


used,  string; 
/jr.srepos 
fx.commenfa 
/x.symrep 


soufost  position. 

oomments, 

symbol.rep; 
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—  ParmTrm  h w  no  m mantle  attnbutoa 


am_addroaa, 


*m_oomp_*poc, 

am_conatraint, 

sm_controUod, 

am_dod_a, 

«a_dofn, 

wn_di*crirmn«nt», 

am_mcoption_dof, 

*mIoxp_typo, 

am_firat, 

am_gonoric_param_a, 

am_in«t_sxp,  " 

am_location, 

wn_normaJiz*d_oomp_*, 

«n_nornMltzodj>*r«m_t, 

am_ob|_dof, 

*m_ob|_typo, 

am_opw«tor, 

am_pocMng, 

am_poa. 

a*n_r«cord_spoc, 

am_r«p. 

am_ateo. 


am_atorago_sizo, 

»m_typo_spoc, 

am_typo_atruct, 

am_vaiiM; 


—  ParaoTroo  haa  no  cod*  attributua 


Without 

*  *>  od_impl_ateo; 


■X‘r 
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RECONSTRUCTING  THE  SOURCE 


One  of  the  basic  principles  of  Diana  Is  that  the  structure  of  the  original 

source  program  is  to  be  retained  In  the  Oiana  representation.  Diana  has  been 
designed  so  that  the  front  end  of  an  Ada  compiler  ( or  any  other  tool  that 

produces  Oiana  from  Ada)  can  include  In  the  Diana  sufficient  Information  so  that, 
to  a  first  approximation  at  least,  the  original  Ada  text  can  be  recreated  from  the 
Diana.  This  ability  enables  an  APSE  tool  such  as  a  pretty-printer  to  work  directly 
from  the  Diana  form,  or  a  syntax-directed  editor  to  operate  directly  on  It.  The 
Diana  form  can  stand  alone  without  reference  to  the  original  source;  some  APSE 
designs  might  elect  to  discard  the  source  and  keep  |ust  the  Diana  form,  using  a 
pretty-printer  when  a  source  listing  Is  required. 

Diana's  design  deliberately  includes  certain  normalizations  of  source 
programs.  These  are  omissions  from  the  Diana  of  enough  Information  to 

reconstruct  the  original  program  exactly,  and  the  effect  of  omitting  these  data  is 

that  the  reconstructed  source  program  Is  of  necessity  normalized  in  certain  ways. 
(The  normalizations  are  discussed  In  Section  III.  3.)  Although  the  Information 
lost  by  making  these  normalizations  could  be  retained  by  providing  additional 
lexical  attributes.  Oiana's  design  Is  predicated  on  the  assumption  that  the  value  to 
the  user  of  this  Information  does  not  lustlfy  Imposing  on  all  Diana  users  the  cost 
In  processing  time  to  record  the  additional  data  or  In  space  to  store  them. 

III.  1 .  General  Principles 

The  structure  of  Diana's  original  design  followed  the  Abstract  Syntax 
Tree  (AST)  of  the  Ada  Formal  Definition  (AFD).  which  was  designed  to  include 
adequate  information  to  permit  source  reconstruction.  Unfortunately,  the  AFD  Is 
based  on  Ada-80,  and  Diana's  (present)  design  Is  based  on  the  syntax  of  on 
Ada-82,  which  differs  from  that  of  Ada-80  In  Important  ways. 

In  Chapter  2.  we  showed  the  connection  between  the  Ada- 82  syntax  and  the 
Oiana  structure  by  Including  the  former  with  the  description  of  the  corresponding 
nodes  and  attributes.  There  Is  a  close  correspondence  between  Ada's  syntax 
and  Oiana's  structural  attributes,  as  shown  In  the  examples  In  the  next  section. 
It  Is  this  correspondence  that  permits  source  reconstruction. 
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The  discussion  on  formalization  of  Oiana  in  Section  1.1.4  on  page  14  is  also 
relevant.  Any  technique  to  solve  the  problem  addressed  in  that  section  will  shed 
light  on  source  reconstruction. 


III.  2.  Examples 

A  few  examples  illustrate  the  reconstruction  process.  Consider  first  the  Aoa 

assignment  statement,  with  syntax  and  Diana  structural  attributes  as  follows: 

Ada  Syntax  (Section  5.2  of  the  Ada  LR*t)« 
a— igmnt_ statement  : 
nans  t—  expression  > 

Diana  rules « 

assign  «•>  as_name  t  NAME, 

aa_exp  j  ZXP; 

The  Aoa  text  corresponding  to  an  assign  node  Is  thus  the  text  that  led  to  the 
NAME  (l.e.  .  the  value  of  the  as_name  attribute),  followed  by  followed  by 

the  text  that  led  to  the  EXP  (l.e..  the  value  of  the  as_axp  attribute,  followed  by 
We  can  summarize  by  writing  that  the  source  text  for  an  assign  node  Is 
<NAHE>  !-  <EXP>  , 

Here  the  angle  brackets  (<>)  indicate  that  the  the  text  for  the  corresponding 
subtrees  must  be  filled  in. 


As  a  second  example,  consider  an  Ada  block: 

Ada  Syntax  (Section  5.6  of  the  Ada  UtM): 
block_statemnt  :  !«• 

[  b/ocfc_slsple_nan*  ] 

declarative jpart ) 
begin 

sequsnce_of_stateaenta 

[exception 

exception  handler  (exception_handler) ] 
end  (b/oc*_siaple_nasM]  ? 


Diana  rules > 

block  ->  aajtamjs  «  iteks_s, 

aa_pfm_jS  i  sm_s . 

as_altarnatlv0_a  >  ai/tepwative _3j 

Thus  for  an  unlabeled  block  node  used  as  a  statement  the  following  text  Is 
generated. 


Reconstructing  the  Source 


Section  III.  2  /  Page  167 


declare 

<ite*_a> 

begin 

<*tn_s> 

<altexnative_s> 

end; 

In  a  tew  places  the  text  to  be  generated  depends  on  the  structural  child.  In 
the  block  statement  example,  it  is  important  that  the  text  exception  be  generated 
only  when  the  sequence  of  alternatives  Is  non-empty  (/.«.,  the 
aa_elternatlve^js  child  Is  empty) .  since  the  syntax  ot  Aoa-82  requires  at  least  one 
exception  handler  after  the  word  exception.  (Ada-80  permitted  an  empty  list  of 
handlers. )  Similarly,  a  private  part  should  be  generated  only  for  a  package  that 
contains  a  non-empty  list  of  private  declarations. 

In  a  similar  vein,  sometimes  the  text  to  be  generated  depends  on  the 
structural  parent.  Again  the  block  node  provides  a  good  example.  When 
block  appears  as  the  descendant  of  a  subprogram_body  node,  the  word  declare 
should  not  be  generated. 

III.  3.  Normalizations  of  the  Source 

A  normalization  of  the  source  is  a  deliberate  omission  from  the  Diana  structure 
of  information  that  would  be  required  to  produce  an  exact  recreation  of  the 
source  text.  Most  of  the  normalizations  are  imposed  by  the  AFD.  Diana 
includes  the  following  normalizations: 

•  The  optional  Identifiers  following  the  reserved  word  end  are  not 
represented  In  Diana.  This  decision  means  that  during  reconstruction 
the  program  is  normalized  either  always  to  Include  the  end  labels  or 
always  to  omit  them. 

•  Diana  does  not  require  that  extra  spaces  between  lexical  tokens  be 
preserved. 

•  Variant  spelling  of  an  identifier,  as  for  example  *FOO*  and  *Foo*  and 
*foo*.  need  not  be  recorded  in  Diana.  This  Is  a  lexical  issue  that 
does  not  affect  the  semantics. 

•  Alternate  writings  of  numeric  constants  need  not  be  preserved.  For 
example.  In 

2  002  0_0_2 

2tuil_iiui  i6tvrt  oieeopp#  zss 
12el  1.2S2  0. 1204-3  01.2*02 

all  the  values  on  each  line  would  be  represented  Identically  in  the 
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Oiana  and  so  would  be  reconstructed  identically.  This  Issue  Is  essen¬ 
tially  the  same  as  the  variant  spelling  of  Identifiers;  Diana  does  not 
require  that  variations  be  preserved. 

A  few  normalizations  of  the  AFO  are  no  longer  In  Diana,  because  of  changes 
In  Aoa-82's  syntax  from  the  Ada-80  syntax  used  In  the  AFD. 

•  In  the  AFD  (and  therefore  in  the  original  design  of  Diana)  .  all  Infix 
operators  (except  the  short  circuit  and  membership  operators)  are 
converted  to  function  calls.  That  is.  each  of 

X  +  Y 
"+"(X,  Y) 

gave  rise  to  the  same  Diana  structure.  Thus  the  original  program 
could  not  be  reconstructed,  since  it  could  not  be  determined  whether 
the  original  had  an  Infix  or  prefix  form  for  these  operators.  Ada-82 
requires  that  this  distinction  be  maintained  to  meet  the  conformance 
rules  for  initial  values  of  default  formal  parameters,  stated  In  Ada  LRM 
Section  6.  3.  1 . 

•  In  formal  parameter  declarations  for  subprograms,  the  mode  In  is 
optional.  Originally,  the  presence  of  the  word  In  In  a  formal  part 
was  not  recorded  In  the  Diana.  The  conformance  rules  of  Section 
6.3.1  requires  that  this  Information  be  maintained. 

•  The  AFD  omits  parenthesized  nodes  If  the  parentheses  are  redundant. 

The  conformance  rules  just  referred  to  require  retention  of  these 
nodes. 


IH.  4.  Comments 

In  order  properly  to  reconstruct  the  source.  Diana  must  be  capable  of  record¬ 
ing  comments.  To  this  end.  every  Diana  node  that  has  a  source  position 
attribute  (i.e. .  all  those  which  correspond  to  points  in  the  source  program)  has 
the  additional  attribute 

lx_commanta  i  cosannta; 

which  is  an  implementation-dependent  type.  The  implementation  may  choose 
how  accurately  comment  positions  are  recorded  and  how  to  associate  comments 
with  particular  nodes. 

The  way  a  user  chooses  to  comment  a  program  greatly  affects  the  ability  of 
any  Internal  representation  to  make  a  meaningful  association  of  comments  to 
nodes.  When  there  is  a  coding  standard  that  enforces  a  commenting  style, 
assumptions  can  be  made  that  make  the  association  easier.  Since  standards 
such  as  these  are  likely  to  be  only  enforced  localiv.  comments  are  treated  as  an 
Implementation-dependent  type.  Diana  makes  requirement  about  either  the 


Reconstructing  the  Source 


Section  III.  4  /  Page  169 


Internal  or  the  external  representation  of  comments,  and  an  implementation  does 
not  have  to  support  the  lx_commenta  attribute  to  be  considered  a  Diana  producer 
or  Diana  consumer. 

One  method  for  attaching  comments  to  tree  nodes  is  described  in  (11.  It 
distinguishes  between  comments  preceding  or  following  the  subtree  which  is 
represented  by  the  node. 
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This  appendix  contains  a  list  of  all  the  class  and  node  definitions  sorted  by 
the  name  of  the  class  or  node.  Class  definitions  are  given  first:  all  class 
names  are  upper  case.  Node  definitions  follow;  node  names  are  lower  case. 
With  each  definition  is  listed  the  section  number  and  page  number  within  Chapter 
2  where  the  corresponding  concrete  syntax  can  be  found. 


ACTUAL  ::=  EXP; 

6.4 

61 

ALIGNMENT  ::=  alignment; 

13. 4. A 

74 

ALTERNATIVE  :  :=  altarnatlvo  1 

5.4 

S3 

pragma; 

ALTERNATIVE  S  ;  :=  alternative  a; 

5.4 

53 

ARGUMENT  : argument  id; 

App.  1 

76 

BINARY  OP  SHORT  CIRCUIT  OP; 

4. 4. A 

46 

BLOCK  STUB  : block; 

6.3 

60 

BLOCK  STUB  :  :=  stub; 

10. 2. B 

70 

BLOCK_STUB_VOID  :  :=  Mock  1 

9.1. A 

65 

stub  I 

void; 

CHOICE  :  EXP  | 

3.7.3.B 

43 

DSCRT_RANGE  1 

others; 

CHOICE_S  :;=  choice_s; 

3. 7. 3. A 

43 

COMP  :  :=  pragma; 

3.7.B 

41 

COMP  ::=  var  | 

3.7.B 

41 

variant_part  I 

null  comp; 

COMPILATION  compilation; 

10.1. A 

69 

COMP  ASSOC  ;  :=  named  I 

4.3.B 

47 

EXP; 

COMP_REP  : :  =  comp_rep; 

13. 4. B 

75 

COMP_REP  ::=  pragma; 

13. 4. B 

75 

COMP  REP  S  :  :=  comp  rep  s; 

13. 4. B 

75 

COMP_REP_VOID  ::=  COMP_REP  1 

3.7.B 

41 

void; 

COMP_UNIT  : :  =  comp_umt; 

10.1. B 

69 

COHO  CLAUSE  :  :=  oond  clause; 

5. 3.  A 

53 

CONSTRAINED  :  :=  constrained; 

3.3.2.B 

36 

CONSTRAINT  :  :=  RANGE  1 

3.3.2.C 

37 

float  | 
ftxod  | 

daert_r»nge_s  | 
dscrmt_agg  regate; 


CONSTRAINT  ;  :=  void; 

3.3.2.B 

36 

CONTEXT  ; ;  =  context; 

10.1.1. A 

69 

CONTEXT  EL  EM  : :  =  pragma; 

10.1.8 

69 

CONTEXT  ELEM  : :  =  use; 

10. 1.1. A 

68 

CONTEXT  ELEM  :  :=  with; 

10.1. 1.B 

70 

DECL  REP  | 

3. 9. A 

44 

use; 

DECL  constant  1 

3.1 

33 

var  I 
number  I 
typu  I 
subtype  I 
subprogram_ded  I 
pocfcago  dad  | 
taafc_deci  I 
qsneoc  I 
exception  | 
deferred_constant; 

DECL  :  :*  pragma; 


3.1 


33 
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oect  s 

;=  dec!  s; 

7.1.B 

62 

DEFCHAR  : :  a  def  char; 

3.5. t.B 

38 

OEFJO 

=  ettrjd  1 
pragma  id  1 

ARGUMENT; 

App.  1 

76 

DCF  10 

-  comp_id; 

C.  7.  B 

41 

OEF  10 

a  const  Jd; 

3. 2. A 

34 

DCF- ID 

=  dacrmt  Jd; 

3.7.1 

42 

DEF- ID 

=  entry_id; 

9. 5. A 

66 

DCF- ID 

a  enum_ld; 

3.5.1 .B 

38 

OEF- 10 

=  exceptionjd; 

11.1 

70 

OEF  10 

a  function_kl; 

6.1. A 

57 

OEF- ID 

a  genericjd; 

12.1. A 

71 

OEF  ID 

a  in _ id; 

6. 1 .  C 

59 

OEFJO 

a  In- out_id  I 
outjd; 

=  Iter  at  ton  Jd; 

6.1.C 

59 

OEF  ID 

5.5. B 

55 

OEF  ID 

a  label  Jd; 

5.1.B 

51 

OEF  10 

a  named_stmjd; 

5. 5. A 

54 

DEF  ID 

a  number_ld; 

3.2.B 

35 

OEF  ID 

a  package  Jd; 

7.1. A 

62 

OEFJO 

a  private  JypeJd  1 

1 _prtvate_type_id ; 

7. 4. A 

63 

DEF  10 

=  procjd; 

6.1. A 

57 

OEF  10 

=  *ubtype_id; 

3. 3. 2. A 

36 

OEF  ID 

=  task  body  id; 

9.1.B 

65 

OEF  10 

=  typejd; 

3.3.1. A 

35 

DEF  ID 

a  varid; 

3. 2. A 

34 

DEF  OCCURRENCE  :  :=  DEF  ID  I 

DEF  OP  I 

DEF  CHAR; 

2.3 

32 

DEF  OP 

;=  del  op; 

6.1. A 

57 

DESIGNATOR  ; :  =  10  I 

OP; 

2.3 

32 

DESIGNATOR _CHAR  :  ;=  DESIGNATOR  1 
used  char; 

4.1.3 

46 

DSCRUT 

.VAR  ;  :=  dscrmt_var; 

3.7.1 

42 

DSCRMT' 

VAR  S  dacrmt  var  s; 

3.7.1 

42 

OSCRT  RANGE  constrained  | 

RANGE; 

3.6.C 

40 

OSCRT  RANGE  :  :  =  index; 

3.6.8 

40 

OSCRT  RANGE  S  :  :=  dacrt  range  a; 

3. 6. A 

40 

OSCRT_RANQE_VOID  ::=  DSCRT_RANGE  1 
void; 

9. 5. A 

66 

ENUM JITERAL  enumjd  I 

def  char; 

3.5. 1.B 

38 

EXCEPTION  DEF  ;  :=  rename; 

8.5 

64 

EXCEPTK)N_OEF  ;:=  void; 

11.1 

70 

EXP  :;= 

NAME  1 

numerlcjlteral  I 
null_accesa  I 
aggregate  I 
stnoq  literal  | 
allocator  | 
conversion  | 
qualified  I 
parenthesized; 

4.4.D 

49 

EXP  :  := 

aggregate; 

4. 3. A 

47 

EXP  = 

binary; 

4. 4. A 

48 

EXP 

membership; 

4.4.B 

48 

EXP  CONSTRAINED  :  :*  EXP  I 

CONSTRAINED; 

4.8 

50 

EXP  3  : 

=  exp_s; 

4.1.1 

46 

EXPVOIO 

EXP  1 
void; 

3. 2. A 

34 

FORMAL  SUBPROG  DEF  :  :=  NAME  1 

box  I 

no  default; 

12. 1  .C 

72 

FORMAL  JTPE_SPEC  :  :=  formal jlecrt  I 

12.1.0 

72 

formetjnteger  | 
formaljlxed  I 
formal_Hoa»; 


GENERIC  ASSOC  ; 

:*  ACTUAL; 

12.3. C 

73 

GENERIC.ASSOC  : 

;a  assoc; 

12.3.8 

73 
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GENERIC  ASSOC  S  generic  assoc  s; 

12. 3. A 

73 

GENERIC  HEADER  :  :=  procedure  1 

12.1. A 

71 

function  | 
p+ctoQ#  tptc; 

GENERIC  PARAM  :  :=  In  | 

12. 1 .C 

72 

m_out  | 
type  1 

subprogram  ded ; 

GENERIC  PARAM  S  generic_param  s; 

12.1. B 

72 

HEADER  :  :=  entry; 

9.5. A 

66 

HEADER  :  :=  function; 

6.1.B 

58 

HEADER  ;  :=  procedure; 

6.1. B 

58 

ID  ::=  DEF  ID  I 

2.3 

32 

USED  IO; 

IO_S  :  :=  ld_s; 

3.2.C 

35 

INNER  RECORD  :  :=  inner  record; 

3. 7. 3. A 

43 

ITEM  =  OECL  I 

3.9. B 

44 

subprogram_body  f 
pacfcage_body  I 
task  body; 

ITEM  S  :  :=  item  s; 

3.9.B 

44 

ITERATION  :  ;=  for  I 

5.5.B 

55 

r«vtrM; 

ITERATION  :  :=  void; 

5. 5. A 

54 

ITERATION  :  :=  while; 

5.5.B 

55 

LANGUAGE  ;  :=  argument  id; 

6.1. A 

57 

LOCATION  ::=  EXP  VOID  1 

6.1. A 

57 

pragma  id; 

LOOP  ::=  loop; 

5. 5. A 

54 

MEMBERSHIP  OP  in  op  I 

4.4.B 

48 

not  In; 

NAME  :  ;=  DESIGNATOR  | 

4.1. A 

45 

UMd_CltV  | 

Indexed  I 
slice  I 
selected  I 
all  I 

attribute  I 
attribute_call; 


NAME  ::=  hmctk>n_call; 

4.1.B 

45 

NAME  S  name  s; 

9.10 

68 

NAME__VOID  NAME  1 

5.7 

56 

void; 

OBJECT  DEF  :  :=  EXP  VOID; 

3. 2. A 

34 

OBJECT  DEF  ;;=  rename; 

8.5 

64 

OP  :  :*~OEF  OP  1 

2.3 

32 

USED  OP  ; 

PACKAGE  DEF  :  ;=  instantiation; 

12. 3. A 

73 

PACKAGE  DEF  ;:=  package  spec; 

7.1. B 

62 

PACKAGE_OEF  :  :=  rename; 

8.5 

64 

PACKAGE  SPEC  ;  :=  package  spec; 

7.1. B 

62 

PACK _BOOT_DE3C  :  :=  block  I 

7.1. A 

62 

stub  I 

rename  1 

instantiation  1 

void; 

PARAM  ;  :=  In; 

6.1. C 

59 

PARAM  In  out; 

6.1.C 

59 

PARAM  ; :»  out; 

6.1.C 

59 

PARAM.ASSOC  EXP  I 

6.4 

61 

moc; 

PARAM  A8SOC_3  :  :=  peram_assoc_s; 

2.8. A 

33 

PARAM  S  ;  :*  peram_s; 

6.1.C 

59 

PRAGMA  ; :»  pragma; 

2. 8. A 

33 

PRAGMA  S  :  pragma  s; 

10. 1.B 

69 

RANGE  :  :*  range  1 

3.5 

37 

attribute  I 

attribute  caH; 

RANGE_VOiO  RANGE  1 

3.5.7 

39 

void; 

REP  aknple_rep  | 

13.1 

74 

address  I 

record_rep; 
REP_VOW  REP  I 


3. 7. A 


41 
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void; 

SELECT  CLAUSE  :  :=  pragma; 

SELECT  CLAUSE  aeiect_dauee; 
SELECT- CLAUSE_S  : ae4ect_ciau»e_*; 
SHORT  ClRCUn_OP  :  :=  *nd_ttwi  I 
of _elee; 

STM  ::=  if  I 

COM  i 

named_etm  I 
LOOP  I 
Mock  I 


9.7. 1.B  67 

9.7.1. B  67 

9. 7.1.  A  67 

4. 4. A  48 

5.1. D  52 


oond  entry  I 
ttmed_entry; 
STM  labeled; 

STM  :  :=  nu»_atm  I 


5.1. B  51 

5.1. C  51 


procedw»_call  I 
exit  I 
return  I 
goto  I 
entry  cal)  | 
(May  I 
abort  I 


STM  :  :=  pragma; 
STM  ::=  terminate; 
STM  S  «tm_*; 
SU8PnOQRAM_DEF 
SUBPROGRAM_DEF 
SUBPROGRAM  DEF 
SUBPROG  RAMDEF 
SUSP  BOOY_OESC 


:  ;=  FORMAL_SUBPROG_DEF; 
:  :=  inatantiation; 

;  :=  rename; 


;  void; 
;;=  Mock  I 
stub  I 


inatantiation  I 
FORMAL_SUBPROG_DEF  I 


5.1. C  51 

9.7. 1. B  67 

5.1.  A  51 

12.1. C  72 

12. 3. A  73 
8.5  64 

6.1.  A  57 
6.1. A  57 


rename  I 
LANGUAGE  I 
void; 

SUBUNtT  BOCTT  ;  :*  aubprogram_body 
peekage_body  I 
taak_body; 

TASK  DEF  :  :=  taak_spee; 

TTPE  RANGE  :  :=  RANGE  I 
NAME; 


TTPE  SPEC 
TYPE__SPEC 
TYPE_SPEC 


::  =  CONSTRAINED; 

FORMAL_TYPE_SPEC; 
;  :*  enum_literal_a  I 
integer  I 


fixed  | 


I 


10. 2. A  70 


9.1.  A  65 

4.4.B  48 

3.2.  A  34 

12. 1 .0  72 

3.3. 1 .B  36 


array  I 
record  I 

aooeaa  I 


derived; 

TYPE  SPEC  Ijpr&ata; 

TYPE- 3PEC  private; 

TYPE  SPEC  :  :*  taak_apec; 

TYPE- SPEC  univeraoljnteger  I 

univeraal_ftxed  I 

gntveraai_reai; 

TYPE  SPEC  : ;»  void; 

UNIT- BODY  ; :»  pockage_body  I 
package  deel  I 
auboiwt  I 

generic  I 

aubprogram.body  I 
aubprogram_ded  I 
void; 

USED  ID  :  :*  uaed_ob|ectJd  I 
“  uaed_name_id  I 

ueed_Mtn_id; 


7.4. A  63 
7.4. A  63 
9.1. A  65 
App.  I  76 


3.8.1  44 

10. 1 .B  69 


4.1. A 


45 
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USED_OP  uaed_op  I 

UMd_bttn_op; 

VARIANT  : :»  variant; 

VARIANT_8  :  :=  variant_a; 
abort  =>  aa_name_a:NAME_S; 
abort  =»  !x_arcpoa : aou rce_poaitk>n , 
bc~oommenU :  commanU; 
aooapt  =>  aa_name:NAME, 

aa_param_a:  PARAM_S, 
aa_atm_a :  STM_S; 

aooapt  =>  Ix3rcpoa:aoorce_poaition, 
lx_oommenU :  commanU; 
acoaaa  »>  aa~_oonatrained: CONSTRAINED; 
aooaao  =>  Ix_arcpoa:aource_po8ition, 
tx~com  manta :  commanU; 
accass  =>  sm_«za:  EXP_VCHD, 

am~atorage_»ze:  EXP_VOIO, 
sm_oontrolied :  Boolean; 
addraoa  =>  aa~  name:  NAME, 
a*_axp:  EXP; 

addraoa  =>  tK_arcpoa:tource _po»itton, 
tx~oommenU ;  commanU; 
aggregate  *>  ~aajiat:aeq  ot  COMP_ASSOC; 
aggragata  =>  ix_arcpoa:aource_poaition, 
lx_oommanU ;  commanU; 
aggragata  *>  *m_axp_typa :  TYPE _ SPEC, 
am_conatraint:  CONSTRAINT, 
am~normalizad_oomp_a :  EXP_S; 
align mant  =»  aa_pragma_a:PRAQMA_S, 
aa_exp_void :  EXP_VOID; 
all  =>  aa_namafNAME; 
all  =»  U_srcpo8:aource_poaitton, 
lx_oommanU :  commanU ; 
all  =>  *m_axp_typa : TYPE  SPEC; 
allocator  ->  aa_oxp_conatrainad:EXP_CONSTRAINEO; 
allocator  ->  lx_arcpoa:aource_poaitton, 
h_com  manta :  commanU; 
allocator  =>  am_axp_typa;TYPE_3PEC, 
am_valua:  valua; 

altarnatlva  =>  aa_cho«ce_8:CHOICE_Sf 
aa_atm_a ;  STM_S; 

altarnatlva  =>  Ixjarcpoa.-aource.jjoaitton, 
tx_oommanU ;  commanU ; 
altamaUva_a  »>  aa_llat;aaq  of  ALTERNATIVE; 
altamativa_o  =>  tx_»rcpoi :  sourca_position , 
lx_oommenU :  commanU ; 
and_than  =>  lx_trcpoa :  aourca_poattton , 
tx_oommanU:  commanU; 
argumant_id  ~>  bt_ajm»rap;aymbol_rap; 
array  »>  aa_dacrt_ranga_a:DSCRT_RANQE_S, 
aa_conatrainad ;  CONSTRAINED; 
array  *>  tx_arcpoa:aoorca_poa*tk>n, 
tx~oommenU :  commanU; 
array  =>  am_aize:EXP_VOIDt 
am  _packlng :  Boolean; 
aaargn  *>  aa_nama;NAME, 
aa_exp:EXP; 

aaatgn  »>  tx_ercpoe:aoorce_posrtk>n, 
ta_oommanU :  commanU; 
aaaoc  *>  aa_daa»gn«tor :  DESIGNATOR , 
aalaetual;  ACTUAL; 
aaaoc  =>  h»_arcpoa :  aourca _poaitton, 
lx_oommenU :  oommanU; 
attr_id  *>  tx_aymrep:aymbol_rep; 
attribute  =>  aa_name:NAME, 
as_ld ;  10; 

attribute  =>  tx_arcpoa:aource_poertion, 
lx_oommanU ;  oommanU; 
attribute  *»  am_exp_type:TYPE_SPEC, 


attrtbute_oaR  *>  aa_nama:  NAME, 
aa_a«p:EXP; 

attribute_caN  *>  t*_arcpoa:  aourea_poattton, 
ix_commenU:commenU; 


13. 4. A 


App.  I 
3. 6.  A 


App.  I 
4.1.4 
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3. 7.3. A  43 
3. 7. 3. A  43 
3.10  68 
3.10  68 
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attributo_call  =»  am_exp_type:TYPE_SPEC, 


binary  *>  aa_exp1:EXP, 

aa  Mnary_op:BINABY_OP, 
aa_oxp2:  EXP; 

binary  »>  lx  arepo8:aouroe_poaition, 
lx_commenta :  commanta; 
binary  =>  am_exp_type:TYPE_SPEC, 
am_yalue:  value; 

Moca  =>  aa_item_a :  ITEM_S , 
aa  atm  a:STM_S, 

*a~attocnattve_a ;  ALTERNATtVE_3; 
Mock  =>  lx_arcpoa:  sounca_poaJtton, 
lx  oomroenta :  commanta; 
box  *  >  lx  trcpoa :  *ourca_po«tton , 
tx_commenta :  commanta ; 
caaa  *>  aa  oxp : EXP, 

aa_altamative_8 :  ALT£RNATIVE_S; 
caaa  =>  fx~trcpot:  aourca_poartk>n, 
lx_oommanta ;  commanta; 
cfxMca_a  *>  aa_llat;aae  ot  CHOICE; 
choica_a  *>  b»_arcpoa:ao«ree_poettion, 
lx_commenta:  commanta; 
coda  =>  aa_nama:NAME, 
aa_axp;EXP; 

coda  =>  lx_arcpoa :  aoorca_poartion , 
lx” commanta:  commanta; 
comp  id  *7  tx_arcpoa :  sourca_poaitk>n , 

”  lx  commanta: commanta, 

tajaymrep:  aymbol_rap; 
comp  id  ->  am_obJ_type:TYPE_8PEC, 

”  am_inlt_axp :  EXP_VOIO, 

«m_oomp_*pac :  COMP_REP_VOtt); 

comp  rap  ->  aa  nama:  NAME, 
aa  axp:  EXP, 
aa.ranga:  RANGE; 

comp  rap  *>  tx 's^P0*  aouree_poaition , 

“  lx  commanta: commanta; 

comp  rap  a  a>  aa_liat:aao  ot  COMP _ REP; 

comp”rap~a  *>  lx_arcpoa:aourca_poaitlon1 
lx_oommenta:  commanta; 
comp  unit  *>  aa_contaxt : CONTEXT, 

aa__unit_body :  UNIT_BOOY , 
aajngiM.* :  PRAQMA_S; 
comp  unit  »>  lx_arcpoa:  aourca_poartion, 

”  lx  commanta: commanta; 

compilation  =>  aa_liat:aaq  ot  COMP_UNIT; 
compilation  *>  lx_arcpo*  aourca_poartk>n , 
lx  commanta: commanta; 
cond  dauaa  *>  aa_axp_void:EXP_VOIO, 

”  aa_atm_a:STM_S; 

cond  dauaa  »  ixJVoP0* :  aource__poartk>n , 

"  lx_commanta:  commanta; 

cond  entry  3>  ea_atm_al:STM_S, 

"  aa_atm_a2:STM_S; 

cond  entry  »>  lx  arcpoa:aource_poattion, 

“  lx  commanta :  commanta; 

oonat  id  *>  tx_arcpoa :  aource_poaition , 
lx_oommanta :  commanta, 
lx~»ymrep :  aymbol_rap; 
oonatjd  *>  am_addraaa :  EXP^VOIO^ 
am  ob|_typa:  TYPE  SPEC, 
am_ob|_det:  OBJECT  OEF, 
amlttraT  DEF  .OCCURRENCE; 

oonatant  *>  aa.Ifa-*:10-8*  .  _ _ 

aa  typo.apac :  TYPE  3PEC, 
aa  ob|oa_def :  OBJgCT_OEF; 
conatant  *>  lxjarepoa:ao«rca_poaitlon, 
lx  commanta:  commanta; 
ccnatrainad  «>“ aa.nama :  NAME, 

aa  conatraint:  CONSTRAINT; 
cowatrainad  »  od~tmpl  _aiza :  Integer ; 
ooeetramed  »>  lx.Iarep©e:aouroe_poalt»ont 
tx.oommanta :  oommanU; 


4.1.4  at 

4.4. A  46 

4. 4. A  48 

4. 4. A  48 

S.G  58 

5.6  58 

12. 1  .C  72 

5.4  S3 

5.4  53 

3. 7. 3. A  43 

3. 7. 3. A  43 

13.8  75 

13.8  75 

3.7.B  41 

3.7.B  41 

13. 4.  B  75 

13. 4.  B  75 

13. 4.  B  75 

13. 4. B  75 

10.1. B  69 

10.1.  B  69 

10.1.  A  69 

10.1. A  68 

5. 3. A  53 

5. 3. A  53 

9.7.2  68 

9.7.2  68 

3.2. A  34 

3.2.A  34 

3.2. A  34 

3.2.  A  34 

3.3.2. B  38 

3.3.2.  B  36 

3. 3. 2.6  38 


1 
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constrained  =>  am  typo  struct  :TYPE_SPEC, 
am_bsss_typs :  TYPE_SPEC, 
am  constraint  .CONSTRAINT; 
context  »  aa_Hst:aeq  of  CONTEXT_ELEM; 
context  »>  lx_srcpoe:aooree_posrtlon, 
tx_oomments :  comments; 
conversion  »»  as_neme:NAM£, 
as~exp:  EXP; 

conversion  =>>  lx_arcpos:source_positlon, 
lx_oomments ;  omments; 
conversion  *>  sm_exp_type:  rrPE_SPEC, 
am_value:  value; 
ded_t  *>  ss_ltat:  seq  of  DECL; 
ded_s  *>  tx_srepos :  *ource_posrtion , 
bc_oomments:  comments; 
def_char  *>  ht_*repoa;  aoorce_posrtk>n, 
lx_oomments :  comments, 
lx_symrep :  symbol_rep; 
def_char  =>  sm_obj_type:TVPE_SPEC, 
am_pos:  Integer, 
snwep:  Integer; 

def_op  s»  lx_srcpoe:aource_position, 

Ix^oomments :  comments, 
tx_symrep:  symbol_rep; 
def  op  »>  am  spec: HEADER, 

smjMdy :  SU8P_BOOY_OESC, 
sm  location: LOCATION, 
snTstub:  OEF_OCCURRENCE, 
sm_Hrst :  DEF_OCCURRENCE; 
deferred^ constant  »  aa_id_a:ID_S, 
as_name:NAME; 

deferred_constant  =>  lx_srcpos:source_pocition, 
ta_comments :  comments ; 

delay  =>  aa_exp:EXP; 
delay  *>  lx_srcpos:  source jpositlon, 
lx  comments: comments; 
derived  =>  as_oonstrained :  CONSTRAINED; 
derived  »>  od_lmpl_sree : Integer; 
derived  =>  lx_srcpos:aource_position, 
lx_comments :  comments ; 
derived  =>  sm_stze:EXP_VOID. 

om_actual_delto:  Rational, 
sm  _pacMng:  Boolean, 
sm_controlled:  Boolean, 
sm_storage_size :  EXP_VdO; 
dscrmt_aggregste  ~>  as_list:aeq  of  COMP_ASSOC; 
dscrmt_aggregate  =>  lx_srcpos:  source_posrtk>n, 
tx_comments:  comments; 

dscrmt_aggregste  =>  sm_normaltzed_comp_s:EXP_S; 
dacrmt_ld  *»  (x_srcpos :  soorce_posrtton , 
tx_comments:  comments, 
lx_symrep :  symbol_rep; 
dacrmt  id  =>  sm_ob|  type:TYPE_SPEC, 
sm  knit  exp: EXP  VOID, 
sm_Mrsf:  OEF_Od6uRRENCE, 
sm_comp_spec :  COMP_REP_VOC; 
dscrmt_ver  ->  as_W_s:IO_S, 
as  name:  NAME, 
as_ot»|ect_det:OeJECT_OEF; 
dsermt.ver  *>  lx_srcpoa:sowrce_poaition, 

Ih  ^AMfleenAa  «  ryhsamaeAai 

daormt_yar_a  »>  asjlst:  seq  of  D9CRMT_VAR; 
dacrmt_var_a  *>  lx_arepoa:aource_position. 


3. 3.2.0  36 

10.1.1. A  68 

10. 1.1.  A  68 

4.6  $0 

4.6  SO 

4.6  SO 

7.1  .B  62 

7.1.0  62 

3.5. 1 . B  38 

3. 5. 1.0  38 

6.1.  A  57 

6.1.  A  57 

7.4.B  63 

7.4.B  63 

8.6  66 

9.6  66 

3.4  37 

3.4  37 

3.4  37 

3.4  37 

3.7.2  42 

3.7.2  42 

3.7.2  42 

3.7.1  42 

3.7.1  42 

3.7.1  42 

3.7.1  42 

3.7.1  42 

3.7.1  42 


dacrt  renge.s  *>  aa_Uat:seq  of  D8CRT_RANQE; 
dsort_range_s  *»  N_srcpos:  source _posttion, 
lx  comments: comments; 

entry  »>  as_d*crt_range  void :  D3CRT_RANQE_VOIO , 
aa_param_a :  PaRam_S; 
entry  *>  lx_srcpoe:  source  ^position, 
comments:  oommonta; 
entry_oaH  »  as_neme:  NAME, 

as_param_assoc_s ;  PARAM_A8SOC_8; 
inlfv  Mi  s>  tx  Mcaomimurom  do  Bit  Win 

wees  ^  m  or  t  e^^e^^ee^smveeeesvg 


3. 6. A  40 

3. 6.  A  40 

9. 6.  A  66 

9.5. A  66 

9.5.0  66 

9.5.  B  66 
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lx_comments :  oomments; 
entry _c*it  =>  *m_norme«zed _per*in_*:EXP_S; 
enbryjd  *>  tx_*rcpo*:*ource_po*itton, 
lx_comments:  comments, 
tx~symrep:  *ymbot_rep; 
entry  Id  >>  «ffl  spec:  HEADER, 

sm_address:  EXP_VOID; 
enum  id  *>  tx_*rcpos :  *ouroe_po*tt>on , 

(x_oomment*:  comments, 
lx_*ymrep :  symbol_rep; 
enum  id  ->  *m_ob)_type:TYPE_SPEC, 

~  sm _poe:  Integer, 

sm_rep:  Integer; 

enum  ttterai.s  =>  asjist:*eq  of  ENUM_UTER  AL ; 
enum~literei  s  *>  cd_impl_*rte: Integer; 
enom_literal~*  =>  lx_wcpo* :  #ocree_po*rtion , 
lx_oomment* :  comment*; 
enum_Meral_*  *>  *m_  size  :EXP_ VOID; 
exception  =>  M_ld_*:ID_S, 

as_exceptlon_def :  EXC£PnON_D€F; 
exception  »>  lx_srcpoa:  source _posrtton, 
fx_oom  merit* :  comment*; 
exception  M  =>  lx_*rcpoe:souree_po«ftlon, 
lx_oommenU :  comment*, 
tx_*ymrep ;  cymbd.rep; 

exception  id  =>  sm_oxeop*»on_.det:EXCEPT10N_DEF; 
exit  ->  a*  nomo_void:NAME_VOtO, 

**_exp_vokl :  EXPJ/OIO; 
exit  a>  lx  *rcpos:*ouroe_position. 

tx~oomment* :  comment*; 
exit  =»  *m_*tm :  LOOP; 
exp_«  »>  as_list;*eq  of  EXP; 
exp  *  =>  lx_srcpos:aource_po*ition, 
tx_comment* :  comments; 
fixed  *>  u  exp:  EXP, 

e*_r*nge_«oid :  RANQE_VOIO; 
fixed  s>  cdJmpl_«teo: Integer; 
fixed  =>  lx_*rcpo* :  *ource_poaition , 
lx_comments :  comments ; 
fixed  =>  sm_*teo:EXP_VOIO. 

*m_actuel_delta:  Rational, 

*m  'bits: Integer, 

*m~be*e__type :  TYPE_SPEC ; 
ftoet  =>  es  e*p:  EXP, 

as_range_void :  RANQE_VOfO; 
ftoet  *>  od_»mpl_size:  Integer, 
ftoet  -*  lx_*rcpos:*ource_poslt»on, 
lx_oomments:  comments; 
ftoet  *>  *m_*tee:EXP_VOIO, 

sm  type_*truct :  TYPE_SPEC , 
sm”bese_type :  TYPE_SPEC; 
for  >>  es  id: ID, 

a*_docrt_renge:  D3CRT_RANQE; 
for  *>  l*_srepo*:*ource_position, 
tot  comments: comments; 
formal  dsert  =>  lx_»rcpo* : socrce_po«rtion , 
lx  comments: comments; 
formal  fixed  *>  lx_*rcpos:*ource_position, 
tx_commont* :  comments; 
formal  lloat  *>  lx“*r«PO«:»®u,'c*-P0*Won- 
lx  comments:  comments; 
formal  integer  =>>  tx_*rcpoa :  #ooroe_po*rtlon , 
lx_oomment* :  comments; 
function  *>  a*_porem_s: PARAM  S, 

aa_name_vwd :  namSj/OIO; 
function  *>  lx_srcpos:soorce_po*ition, 
lx_comments:  comments; 
function  caN  *>  as_name:  NAME, 

as  _param_«*ooc_*:PARAM_ASSOC_S; 
function  call  »>  lx_*rcpo* :  source _pomikm , 
lx_comments :  comments; 
funeUon.csM  »>  sm_exp_type : TYPE_SPEC , 


•m_normalized_parem_s :  EXP_3, 
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bc_prafl»:  Boolean; 

functkm_td  *>  tx_arcpoa:aoorca_poaitlon, 
tx_oommenta :  commanta, 
lx  aymrop:aymbol_rep; 
functlonjd  *>  am  apec : HEADER , 

am"body:SU8P  800Y  DESC, 
am  location :  LOCATION , 
am  atub:D€F  OCCURRENCE, 
am~Hrat :  DEF  "OCCURRENCE; 
generic  *>  aa  Id:  ID, 

aa _fla**arto_param_a:QENERIC_PARAM_S, 
aa  ganarie  header:  GENERIC_HEADER; 
ganarie  »»  tx_»rcpo* :  aowrce_poaition , 
l»~oommonta:  commanta; 

gananc_aaaoc_a  »>  *a_1iat:  aeq  of  QENERIC_ ASSOC; 
generie_aeaoc_a  =>  bi_$rcpoa : aource_poartion, 
h_commenta ;  commanta; 
genartc_W  =>  N_aymrep:aymbol_.rep, 

tx_arcpoa ;  aource_poaitlon . 

Ix~oommente :  commanta; 

ganarie  Id  »>  am  ganarie  param  s:  GENERIC  PARAM  3, 
am  apec: GENERIC  HEADER, 
am~body :  BLOCK_STUB  VO», 
am  (lrat:DEF  OCCURRENCE. 
am"atub:  OEF_OCCURRENCE; 
genertc_param_a  =>  aa_list:  aeq  of  GENEHIC_PARAM; 
ganartc_param_a  =>  tx_srcpoa :  sou rca_po*rtlon , 
h  comman ts :  commanta; 
goto  *>  aa_nama :  NAME; 
goto  *»  lx_arcpoa;aourca_poaltton, 
lx_eommenta:  commanta; 
id_a  »»  aa_Nat:aeq  of  10; 
id_a  s>  tx_arepoa:aowrce_poaitlon, 

™  lx_oommente:  commanta; 

If  *>  aa_ltat:aaq  of  COND_CLAUSE; 

If  *>  bc_arcpoa:aourca_poaitionl 
tx_oommanta :  commanta; 
in  a>  aa_id_e:lO_S. 
aa_nama:  NAME. 
aa_axp_void :  EXP_VOIO; 
m  *>  lx_arcpoa:ao«irca_poaitlon, 
tx_oommanta ;  commanta, 
lx_dafautt:  Boolean; 
tn_id  =>  tx_arcpoa:aouroo_poaition, 
lx_commente ;  commanta, 

•»_aymrap ;  aymbol  rep; 
in  id  =>  am  obi  type :  TYPt_SPEC , 
am"  nit  axp:EXP_VO«, 
am_Hrat :  COOCCURRENCE; 
in_op  *»  (x_arcpoa.aooroe _poartion, 
tx_commarrt» :  commanta; 
in_out  »  aa_id_a:ID_S, 
aa_nama:NAME, 
aa_axp_void ;  EXP_VO»; 
m_out  *>  lx_arcpoa:aoorea _poaitlon, 
lx_com  manta :  commanta; 
ln_out_!d  *>  lx_arcpoa:ao«irca_poaltlon, 

”  lx_oommonta :  commanta. 

Ix_aymrap :  aymbol  rap; 
in  out  id  *>  am  obj_typa:  TYPf_SPEC, 

am^flrat :  DEF  _OCCU  RRENCE ; 

Indon  *>  M_nama:NAME; 

Indw  »>  tx_arcpoe:aoerce_poeitlon, 
btjoommanU;  oommanta; 
indaaad  *>  aa_name:NAME, 
aa_axp_a:  EXP_S; 

Indaaad  *>  te_arcpoa:aoMtoe_poattion, 
l»_commanta ;  commanta; 

Indaaad  ■>  am_eapjtype:TYPE_SPEC; 
innar_raeord  *>  aa_Hat:aaq  of  COMP; 
inner_reoord  »>  ix_arcpoe:aovroe _poaitlon, 
te_commanta :  commanta; 

InatantMtton  »>  ae_nama:NAME, 

aa_gananc_aaaoc_* :  QENERIC_AS30C_8; 
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instantiation  *»  tx_srcpo* :  soufce_pos<tion , 
tx,oommonts :  oomments; 

12.3. A 

73 

instantiation  =»  sro  deci_s:  D€Ci._3; 

12.3. A 

73 

integer  ■>  as_range:  RANGE; 

3.5.4 

38 

integer  *>  cd_impl_aize :  integer; 

3.5.4 

38 

integer  *>  ix_srcpos :  soorce_position , 
lx_oomments :  comments ; 

3.5.4 

38 

integer  =>  tm_s»ze: EXP_VOiD, 

*/n_type_*trvct:  TYP€_SP£C, 

*m_beee_type :  TfPE_SPEC; 

3.5.4 

38 

ltem_s  =>  as_l(st:seq  of  ITEM; 

3.9. B 

44 

ltem_s  =>  !x_srcpos:*ooree_p©sitlon, 
tx_conwnents :  comments; 

3.9. B 

44 

lter»tion_M  *>  ix__srcpos:*ource_po*rtion, 
tx_  comments:  comments, 
tx_symrep:  symbol  rep; 
iteretton_ki  s>  sm__ob(L_type :  TYPE_SP€C ; 

5. 5. a 

55 

5.5.B 

56 

t_prtve te  *>  lx_srcpoa:*oorce_positton. 

Is- comments:  comments; 

7. 4. A 

63 

l_prtvete  =>  sm_dl*crtminant*:OSCRMT_VAR_S; 

7.4. A 

63 

l_prtvate_type_ld  *>  tx_srcpos:*oorce_position, 
tx_comments :  comments, 
lx_synwep :  symbol  rep; 

7. 4. A 

63 

1  _prtvete_type_id  =»  sm_type_spec:  TYpE_SP€C; 

7.4. A 

63 

lebel_M  =>  lx_srcpos:*ource_poxitk>n, 
lx_oomments:  comments, 
lx~symrep :  symbol  rep; 

5.1.B 

51 

Iebe4_kl  =>  sm_stm:STM; 

5.1.8 

51 

labeled  =>  ss_id_s:10_S, 

*s_stm:STM; 

5.1.B 

51 

labeled  =>  tx_srcpos : source _postUon, 
tx~comments :  comments; 

5.1.8 

51 

loop  *>  as_lterstion :  ITERATION , 
as_stm_s ;  STM  S; 

5. 5. A 

54 

loop  ->  fx_srcpos :  soorce_posrt ion , 
lx_comments :  comments ; 

5. 5. A 

54 

membership  *»  ss_exp :  EXP , 

aa_memberahip op:  MEMBERSHIP_OP, 
as_type_rsnge :  TYPE_RANGE; 

4.4.B 

48 

membership  ->  tx_srcpos:  source _position, 
tx_commenta :  comments; 

4.4. B 

48 

mambership  *>  sm_exp_type:TYPE_SPEC, 
sm_value:  value; 

4.4.B 

48 

name_t  *>  as_Hst:seq  of  NAME; 

9.10 

68 

name_s  ->  bt_srcpoa:aource_positlon, 
lx_comments :  comments; 

9.10 

68 

named  =>  aa_choice_s:CHOIC£_S, 
as_exp:EXP;  ~ 

4.3. B 

47 

named  ->  lxjsrcpos:source_posrtk>n, 
lx_eomments :  comments; 

4.3.  B 

47 

named_stm  *>  aa_ld:IO, 

~  aa_stm :  STM; 

5. 5. A 

54 

named_stm  *»  tx_srcpos: source jposttton, 
l»_oommenta :  oomments; 

5.5.A 

54 

named_stm_td  *>  lx_srcpos:soorce_posttlon, 

"  bc_comments;  comments. 

b»_symrep :  symbol.rep; 

5. 5. A 

54 

nemed_stm_id  »»  sm_stm:STM; 

5. 5. A 

54 

no_deteutt  »>  tx_srcpos:socrce _posrtion, 
tx_comments:  comments; 

12. 1  .C 

72 

not_in  »>  lx_srcpos :  eooroe_pos*tton , 
lx_oomments :  oomments; 

4.4.B 

48 

mHI_aceess  *>  lx_srcpo» : source_position , 
tx_oomments :  comments; 

4.4.0 

48 

noH_aoosas  »>  sm_exp_type :  TYPE_3PEC , 
sm_vaioe :  value ; 

4.4.D 

48 

nu«_comp  »*  tx_srcpos:souroe_posttton, 
bt_oomments :  oomments; 

3.7.8 

41 

mdl_atm  *>  lx_srcpos :  soorce_posrtk>n , 
bi_oomments :  comments ; 

5.1.F 

52 

mimber  »>  as_id_s|IO_3, 
aa_exp :  EXP; 

3.2.B 

35 

mimber  »  bt_srcpoa:aouroe_position, 
tx_oommenta :  oomments; 

3.2. B 

35 
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numb*r_kl  =>  lx_srcpos:source_pos«tion, 

”  tx_oommerrts :  comment*, 
lx~symrep :  symbol_rap; 
number_id  *>  sm_obi_type:TYPE_SPEC, 
sm_ <nit_exp :  EXP; 

numerte_literal  =>  lx_srcpos:souroe_position, 
lx_comments :  comments, 
lx_numrep :  number_rep; 
numeric_literal  =»  sm_exp_type:TYPE_SPEC, 
im^vsiua :  vstoa ; 

or_eise  =>  lx _ srcpos :  »ourca_posrtion , 

b«_comiT>*nl» :  comments; 
others  *>  lx_srcpos :  *ource_posrtion , 
lx  comments :  comments; 
out  =>  as_»d_s:ID_S, 
es  name: NAME, 
as_exp_void :  EXP_VO*>; 
out  ta_srcpos:*ource_position, 
lx_comments :  comments ; 
out_Jd  *>  lx_trcpos:source_pos«tlonf 
tx_comments :  comments , 
lx_tymrep :  symbol_rep; 
out  id  =>  sm  ob|_type:TYPE  SPEC, 

sm^Nrst :  DEF_OCCURRENC£; 
package  body  =>  as_id:IO, 

ss_biock_stub :  BLOCK_STUB; 
pechage_body  ■>  lx_srcpos:  source _po«tion, 
lx_commenta :  comments; 
peekage_ded  =>  as_id:IO, 

as_pacfcage_def :  PACKAGE_DEF; 
pacfcage_ded  =>  bt_srcpos:aource_pos*tk>n,~ 
lx~comments :  comments; 
package_M  =>  tx_srcpot:  source_positk>n, 
tx_comments :  comments, 

Ix  symreo :  symbol  rep; 
packagejd  =>  sm  spec:  PACKAGE  SPEC, 

sm  body :  PACK_BODy  OESC, 
sm  address:  EXP_VONX 
sm_stub :  OEF  OCCURRENCE , 
sm_Hrst :  DEF_OOCURRENCE; 
peckage_spec  *>  as_ded_s1:DECL_S, 
as_ded_s2:  OECL_S; 

package_spec  *>  tx_srcpos :  sou rce_positton , 
lx_oomments :  comments ; 

param_as*oc_s  *>  as_list:saq  of  P  AH  AM  _  ASSOC; 
param_aa*oc_s  =>  lx_srcpos : *ource_po«ttk>n , 
tx_oomments :  comments; 
param_s  »>  as_Hst:aeq  of  PARAM; 
paramos  =>  tx_srcpos:aouree_position, 
lx_oomments :  comments; 
parenthesized  =>  ss_exp:EXP; 
parenthesized  *>  lx_srcpos:  source _po*rtton , 
lx_comments :  comments; 
parenthesized  »>  sm_exp_type:TYPE_3PEC, 
sm_value :  value; 
pragma  *>  as_id:ID, 

as _peram_assoe_s:PARAM_ASSOC_S; 
pragma  *>  tx_srcpos:souree_position, 
tx_oomments :  comments; 
pregma_id  *>~ ss_Ust:seq  of  ARGUMENT; 
pragma_id  *>  lx_symrep: symbol  rap; 
pregma_s  *>  as_ltst:seq  of  PRAGMA; 
pragma_s  *>  tx_srcpos ;  source _posttton , 

lx _ comments :  comments; 

private  *>  lx_srcpos:source_position, 
lx_comments :  comments; 
private  *>  sm_discnmtn*nts :  D8CH MT_VAR_S; 
prtvete_type_ld  ■>  bi_srcpos: source Jposrtion, 

”  b»_oomments:  comments, 

lx.symrep:  symbol  rep; 

prtvete_type_id  »>  sm_type_spec :  TYft_SPEC; 
preejd  »>  ix_srcpo#:*oorce_pasitton, 
tx_oomments ;  comments, 
tx_*ymrep :  symboi_rep; 
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proejd  =>  sm_*pec:  HEADER, 

sm_toody:  SUSP  BOOY_DESC, 
sm  location: LOCATION, 
sm_stut> :  D€F_OCCURRENCE , 
sm_flrst:  DEF_OCCURRENCE; 
procedure  =>  «*_param_*:PARAM_S; 
procedure  =>  lx_*rcpos:*ource_po*ltk>n, 
lx_  comments:  common  Is; 
procedure_ceM  *>  as_name:NAME, 

**_param_as*oc_s :  P  ARAM_ASSOC_S ; 
procoduro_caM  =>  ix_srcpos:*ourco_po*rtion, 
tx_commont* :  comment* ; 

procedure_caH  *>  sm_nonnal(zed_peram_s:  EXP_S; 
qualified  =>  u_nvno :  NAME, 
as_exp:EXP; 

qualified  =>  bt_srcpo* :  sour eo_po*rtK>n, 
lx  comments :  comments; 
qualified  =>  sm_exp_type : TYPE_SPEC , 
sm_vaiue:  value; 

raise  »>  aa_namo_voM:NAM£_VOIO; 
raioo  =>  lx_*rcpo*:source_po*ition, 
lx_commeot* :  commonti ; 
range  =>  as_oxpl:EXP, 
aa_oxp4:EXP; 

rango  =>  lx_srcpos:*ource_position, 
lx~comments :  comments; 
rango  =>  *m_bese_type:TrPE_SPEC; 
record  =>  as_ll*t:soq  of  COMP; 
record  =>  lx_srcpos : source_position, 
lx  common  to :  comment* ; 
record  =>  sm_size:EXP_VOID, 

am_dlacrlmin*nta :  DSCRMT_VAR_S, 
sm_pacMng :  Boolean, 
sm_rocord_*poc :  REP_VOID; 
rooord_rep  *>  as_name:NAME,_ 

aa_a!tgnment :  ALIGNMENT, 
as_comp_rep_s :  COMP_REP_S; 
rocord_rop  =>  lx_srcpo*:  *ource_positlon, 
lx_comments :  comment*; 
rename  =>  «*_nomo:  NAME; 
rename  =>  lx_srcpo«: source _po*itlon, 
tx_commen'.s :  comment* ; 
return  =>  a*_oxp_vok< :  EXP_VO(D; 
return  =>  lx_srcpo*: source _po*ttlon, 
ta_commonts :  comments; 
reverse  =>  aa_id:ID, 

a*_d*crt__ranqe :  DSCRT_RANGE; 
reverse  =>  bt_srcpo*:source_position, 
tx_oommonts :  comments; 

select  =>  aa_oelsct_cl*uoe_* SELECT_CLAUSE_S , 
ea_stm_s :  STM_S; 

select  =>  lx_srcpos: source _po*ition, 
lx_oomments:  comments; 
select_deuee  =>  as_oxp_void :  EXP_VOID, 
e*_stm_s :  STM_S; 

select_deuse  »>  !x_srcpo*:sourc* _po*rtk>n, 
lx_comment* :  comments; 

eelect_cleuae_*  *»  as_list:  seq  ot  SELECT_CLAUSE ; 
select_deuee_*  =>  lx_srcpos :  sourco_posrtion , 
bt_comment* :  oommont* ; 
selected  =>  as  name: NAME, 

ea_de*lgnator_cHar:  D€SK3NATOR_CHAR; 
selected  »>  h_srcpo*  •.  source_pos*tton , 
lx_oomments :  comments; 
selected  *>  *m_exp_type : TYPE_3PEC ; 
slmpie_rsp  *>  **_  name  .NAME, 
ea_exp:EXP; 

simple_rep  »>  tx_srcpo* :  *ource_posttk>n , 
lx_oomment* :  comments; 
slice  *>  as  name: NAME, 

aa_d*crt_range :  08CRT_RANOE; 
sMee  ■»  (x_srepo*:souroe_poattlon, 
lx_oomment» :  comments; 
sftce  *>  sm_*ap_type:TTPE_8PEC, 
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sm_constraint :  CONSTRAINT ; 
stm_s  *»  as_llst:»eq  of  STM; 
stm~s  =>  !x_srcpos :  *ource_poxrt>on, 
lx_comments :  comments; 
strtng_literai  =>  tx_srcpos :  *ource_po*rtion , 
tx_comments :  comments, 
txjrymrop ;  symbol_rep; 
string  litoral  =>  sm_exp_type :  TYPE  _  SPEC, 
sm_con*tr«int :  CONSTRAINT, 
sm~v»lue:  value; 

stub  =>  txsrcpos :  source_position , 
tx~comments :  comments; 

subprogram_body  ->  as_designator:  DESIGNATOR, 
as- header:  HEADER, 
aa_Wock_stub:  BLOCK_STUB; 
subprogram_body  =>  lx_srcpos:source_positlon, 
lx_com  merits :  comments; 

subprogram_ded  =>  as_designator :  DESIGNATOR, 
as_header :  HEADER , 
as_subprogram_def :  SUBPROGRAM_DEF ; 
subprogram_ded  =>  lx_srcpos:source_positlon, 
lx_oomments :  comments; 

subtype  =>  as_id:IO, 

as_oonatrained :  CONSTRAINED; 
subtype  ->  btJsrcpos:source_positlon, 
lx_comments :  comments ; 
subtype_M  lx_srcpos:source_position, 
lx_comments :  comments, 
lx_symrep :  symbol_rep; 
suMype_ld  =>  sm_type_spec; CONSTRAINED; 
subunit  =>  as_name:NAME, 

aa_subunit_body :  SUBUNIT_BOOY ; 
subunit  =»  lx_srcpos:source_position, 
lx_oomments :  comments ; 
taak_body  =>  aa_id:ID, 

as_D»ock_stub.  BLOCK  STUB; 
tash_body  =>  tx_srcpos:source_position, 
tx_comments :  comments ; 
task_body_id  ->  lx_srcpos:source_poaition, 
lx~eomments :  comments, 
tx_symrep:  symbol_rep; 
taak_body  id  =>  sm_type_spec:TYPE  SPEC, 

sm_body:  BLOCK  STUB  VOID, 
sm  first :  DEF_OCCURREncE  , 
sm_stub:  DEF~OCCURRENC£; 
taak_ded  »>  as  id: ID, 

as~task_def:TASR_OEF; 
tasfc_ded  =>  tx_arcpos: source _posrtkm, 

~  lx  comments: comments; 

task.spec  =>  as_ded_s:OECL_S; 
task_spec  *»  lx_srcpos:  source _poeition, 
lx_comments :  comments; 
taak_spec  =»  sm_body:BLOCK_STUB_VOID, 
sm_addrees :  EXP_VOiO , 
sm_storege_sireTEXP_voiO ; 
terminate  ->  lx_srepos:  source _posttion, 
lx_oomments :  comments; 
timed_entry  »>  as_stm_s1  :STM_S, 
as_«tm_s2 :  STM_S; 

tlmed_entry  =>  tx_srcpos:aourcej>osrtk>n, 
lx_comment* :  comments; 
type  3>  as_id:IO, 

as_dacrmt_var  s:DSCRMT_VAR_S, 
aa_type_spee  :TrPE_SPEC; 
type  *>  tx_srcpoa:  source _pos«t>on, 
tx_oomments :  comments; 
type_id  »>~  lx_»rcpos:  source  _posrtion, 

lx _ comments :  comments, 

«x_symrep :  symbd_rep; 
type  id  »>  sm_type  spec: TYPE  SPEC, 
sm_first  :T)eF_OCCUffRENCE; 
untueraal_fixed  »  ; 

.Integer  *>  ; 

_rea I  *>  ; 
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uw  =>  as_Hst:seq  of  NAME; 
un  =>  tx_*rcpo«:  8ourco_po*ition, 
lx_commont*:  comments; 
used_bitn_id  =>  lx_*rcpos:  *ource_po*ition, 
lx_comments ;  comments , 
lx_symrep ;  symbol_rep; 
used_bitn_id  =>  sm_opermtor;  operator; 
used_bltn_op  =>  tx_srcpos:30uree_position, 
lx_comments:  comments, 
lx_symrep :  symboi_rep; 
used_bttn_op  =>  *m_operator :  operator; 
used_char  =>  lx_»rcpot :  sou  rce_  position, 
lx_comments :  comments, 
lx_symrsp:  symboi_rep; 
used_cher  =»  sm_defn;OEF  OCCURRENCE, 
sm_e*P_type  rtYPE_SPEC, 
sm_veloe:  value; 

used_neme_td  *>  tx_srcpos ;  source _posrtion, 

’  tx_comments ;  comments, 
lx_symrep:  symboWep; 

used_name_id  =>  sm_defn;  DEF_OCCURRENCE; 
used _oto  (ect _td  s>  tx_srcpos :  source _po»ition , 
lx_comment* ;  comments, 
lx_symrep;  symbot_rep; 

used_ofc|ect_id  =>  sm_sxp_type :  TYPE  SPEC, 

sm_defn :  DEF_OCC0rRENCH, 
sm_velue:  value; 

used_op  =>  tx_srcpos :  source _position, 
lx_comment* ;  comments , 
lx_symrep:  lymboirap; 
used_op  *»  sm_defn:DEF_OCCURRENC£; 
ver  =>  es_kl_8:ID_S, 

es_type_spec :  TYPE_SPEC , 
ss_ob  ject_def :  OBJECT_DEF ; 
ver  =>  tx_srcpos:  source_posit(on, 
lx_comments ;  comments' 
ver_id  =>  tx_srcpos;  source  A*-tlon, 
lx_c©mments:  co  \wrts, 
tx_symrep ;  tymboi_rsp; 
ver_id  =>  sm_ob|_type : TYPE_SPEC, 
sm_ftddress ;  EXP_VOID , 
sm_ob|_def :  OBJECT_DEF; 
variant  s>  as_cho*ce_s :  CHOICE  S , 

as_reoord ;  INNER_RECORO; 
variant  =>  tx_srcpos : source_position , 
lx_comments :  comments; 
variant_part  =>  as_nama: NAME, 

as_variant_s ;  VARIANT_S; 
variant _part  =»  lx_srcpos;source_position, 
tx_comments :  comments; 
varient_s  =>  as_Ust:  seq  of  VARIANT; 
vertent_s  =>  lx_srcpos;source_pos>tion, 
lx_comments :  comments ; 

void  s>  ; 

while  =»  ae_exp:  EXP; 
while  ->  lx_srcpos:source_position, 
tx_oomments :  comments; 
with  s>  as_Kst;seq  of  NAME; 
with  a>  lx_srcpos: source _positlon, 
lx_comments ;  comments; 
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57,  62,  66,  71 
81,  54,  56 
37,  44,  65 
57,  62.  66,  71 
36,  36,  63,  68 
36,  38,  36 

46.  47,  46,  46,  50,  61 

33,  34,  36.  36. 

39.  40,  41,  42. 

46,  46,  47,  46. 

81,  82,  83.  54, 

57,  59,  86,  60, 

63,  64,  65,  65. 

69.  70,  71,  72,  .  . 

75 


mm* 
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atm_* 

-  »— * - 

eumu  mini 

abb 

autproqr*iw_bo6y 
autaroorwi  **d 
wMyp* 

aub«ntt~ 
symbol  rap 


tMk_bo*y 
taak_body  Id 
tMK_4*el 


Um*d_*ntry 


us* 

oaod_b*n_ld 

uaad_b*n_op 

us*d_char 

usa4_nams_M 

us*d_oPJ*ct_ld 

uaM_op 

y||g^ 


var 

v*r_kJ 
variant 
variant _p*rt 
variant_* 
voU 


5.9,  9.1. A,  6.1.9,  6.1.C,  6.3,  6.4, 

7.1. A,  7.1.9,  7.1. C,  7.4. A,  7.4.9, 
6.4,  6.5,  9.I.A.  9.1.9,  9.5.A, 

9.5.9,  9.5. C,  9.6,  9.7.1. A, 

9.7. 1.9,  9.10,  9.7.2,  9.7.3, 

10.1. 1. A,  10.1. A,  10.1.9,  10.1.1.9, 

10.2. A,  10.2.9,  11.1,  11.3.  12.1.  A, 

12.1.9,  12.1.  C,  12.1.0,  12.3.A, 

13.3,  13.4.A,  13.4.9,  13.5,  13.8) 
;5.1.A1 

4.4.0) 

'6.1. A.  7.1. A,  9.1. A,  10.2.9) 
'3.9.9,  6.3,  10.1.9,  10.2. A] 

3.1,  6.1. A,  10.1.9,  12.1.C) 

'3.1,  3.3.2.A] 

3.3.2.A) 

10.1.9,  10.2.A] 

’3.2.A,  3.2.9,  3.3. 1. A,  3.3.2.A, 

5.5.1. 9,  3.7.9,  3.7.1,  4.1.A, 

4.4.0.  5.1.9,  S.S.A,  5.5.9,  6.1. A. 

8.1.  C,  7.1. A,  7.4.A,  9.1.9,  9.5.A, 

1 1.1.  12.1. A,  App.  I] 

3.9.9,  9.1.9,  10.2.A] 

9.1.9) 

13.1.  9.1. A) 

{9.1.  A) 

’9.7.1. 9) 

5.1.0,  9.7.3] 

3.1.  3.3.1. A,  12.1.C) 

3. 3.1.  A] 

App.  I] 

wApp.  I] 

[APP.  I] 

•■3.9. A,  9.4,  10. 1.1. A] 

4.1.  A] 

4.1.  A) 

‘4.1.  A.  4.1.3] 

4.1.  A] 

4.1.  A) 

4.1.  A] 

‘4.1. A,  4.1.4,  4. 4. A,  4.4.9,  4.4.D, 
4.6,  4.7,  4.6,  6.4] 

’3.1,  3.2.A.  3.7.9] 

3.2. A] 

'3. 7. 3. A] 

3.7.9,  3.7. 3. A] 

‘3.7.3.A1 

f2,  3.2.A,  3.3. 2. 9,  3.5.7,  3.7.A, 

1.7.9,  3.8.1,  5.5. A,  5.7,  8.1. A, 
T.I.A.  9.1. A,  9.5. A,  10.1.9,  11.1] 


10.1.1.9] 


51 

49 

57,  62,  68,  70 

44,  60.  69.  70 
33,  57,  69,  72 

33,  36 
36 

66.  70 

34.  36.  36,  36.  41, 

45,  46,  51,  54,  55, 

56.  62.  63,  65,  66. 

71,  76 

44.  66,  70 
86 

33.  65 
65 
67 

52.  66 
33,  35,  72 
36 
76 
76 
75 

44,  64.  69 
45 
45 

46,  46 
45 

45 

46 

45,  47,  46,  46.  50.  61 

33,  34.  41 

34 

43 

41,  43 
43 

32,  34,  36,  39,  41,  44, 
54,  56,  57,  62.  65,  86, 
96,  70 
56 
70 
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This  appandlx  Is  an  index  ol  all  of  the  attributes  which  occur  In  Diana  tree 
nodes.  Each  attribute  Is  shown  in  the  form 

label  s  type  [secfcion-nuaber-list]  page-maber-list 
The  section  number  list  gives  all  the  sections  of  Chapter  2  which  make  use  of 
the  attribute.  The  page  number  list  gives  pages  of  this  document  on  which  the 

attribute  may  be  found.  Either  list  may  be  split  across  several  lines.  The 
attributes  are  grouped  into  four  sections:  structural,  lexical,  semantic,  and 
code. 


VI.  1.  Structural  Attrlbutas 

Structural  attributes  define  the  basic  shape  of  the  Diana  tree. 


M_actual:  ACTUAL 
U_alignnwnt:  ALIGNMENT 
M.iHwihMw  »:  ALTERNATIVES 
u_Wiwy_opf&MARY  OP 
tt_Mock_stub:  BLOCir  STUB 
M_cho*ca_«:  CHOICE ,S 
M_CQmp_rep_* :  COMp_R€P  S 
M_oon«trWnwl:  CONSTRAINED 
M_oonatraint :  CONSTRAINT 
••.contact:  CONTEXT 
«_M  il :  OECES 
«s_dool_«2 :  OECL  8 
:0ECL_3 

LTOR 

:  OESKINATOR.CMAR 


6.4] 

13.4.A] 

*5.4,  5.6] 

{4. 4.  At 

[6.3,  7. 1.C,  9.1.8] 
3.7.3.A.  4.3.B.  5.4] 


56 


13. 4, A] 

3.3.2.A, 

3. 3.2.8] 

10.1.8] 

7.1.8] 

7.1.8] 

9.1.  A] 

6.1.  A,  6.3,  6.4] 


3.4,  3.6.A,  3.9] 


61 
74 
93. 

46 

90.  63. 
43.  47. 
74 

36.  37, 


68 

S3 

40,  44 


_var_» :  OOCRMT  VAR.S 
_____ ...  ang* :  OOCRT  RANGE 
M_4Mrt_raRga_«:OOCEr_RANOE_6  ... 

'  ‘  •_vo*d :  D0(*r_RAN5e_V0» 

_  [9. 8.  A] 

n.Ool :  EXCEFTX5N.DEF  - 


tl.S] 

3.1.  A] 

1.2.  6.5.8] 

6.Aj 


M_«xp:EXP 


p  voM :  ^Sp_VOIO 


EXP.00N6TRAINED 

!4.6] 
4.1.1] 
6. 3. A. 
3.4. A] 

»_•:  QCN6RIC_A860C_8 

_  [13 

GENERIC  HEADER  [12 
is :  OENERiC_PARAM_S 


11.1] 

3.6,  4.4.A] 

.3.5,  4.4.A] 

[3.2.8,  3.5.7,  3.5.9,  4.1.4,  4.3.8, 

4.4.8,  4.4.0,  4.6,  4.7,  5.2,  6.4, 

5.5.8,  9.6,  13.3,  13.4.8,  13.5, 
13.6] 


62 

68 

57,  60,  61 

46 

36 

46.  56 


70 

37,  46 
37.  46 
36,  39,  47, 
52.  53.  85, 


74, 


80, 

75 


6.7,  8.8,  6.1. C,  9.7.1. 8,  53,  86,  86,  67,  74 


HEADER 


3.A1 
1.A] 

112.1.  A] 

6.1.A,  8.3] 

2.8.A,  3.3.1. A,  3.3.2.A,  4.1.4, 
.6. A,  5.5.8,  7.1. A,  7.1. C,  9.1.* 


73 

71 

71 

87,  80 
38,  36,  35. 

62,  63,  68. 


47,  84, 
71 
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oo_W_o:W_S 

s:  ITEM  8 
ITERATION 
oo  Notroeq  of  ALTERNATIVE 
MjttlMq  Of  ANQUMENT 
II  M:nq  Of  CHOICE 
M_Not:a«q  of  COMP 
00  Nottooq  of  COMP  AS80C 
oo  Not:ooq  of  COMP  PEP 
00  Not-.aoq  of  COMP.UMT 
00_Not:aoq  Of  COHO  CLAUSE 
oo_Hot:aoq  of  CONTACT  ELEM 
Oo_Not:aeq  of  OECL 
os  Not:ooq  of  08CRMT  VAR 
oo_Not:ooq  of  OSCRTjUNGE 
00  Hot:ooq  Of  EMUM_UTERAL 
oo  Kot'ooa  af  EXP 
ao~Not:oeq  of  GENERIC  ASSOC 
oo_lM:aoq  of  GENERIC_PARAM 
oo_Hot:soq  of  10 
oo_Not:ooq  of  ITEM 
oo_Hot:ooq  of  NAME 
00  Not:ooq  of  PARAM 
oo  Hottooq  Of  PARAM.A880C 
oo  Nof:ooq  of  PRAGMA 
aoJM:ooq  of  SELECT_CLAU8E 
00  Not:oaq  af  STM 
oo.NaCooq  of  VARIANT 
oo  momboraMo  op:MEM8ER8fMP_0P 
o«_nomo:NAME 


8.1.8,  12.1. A] 

[3.2.A,  3.2.8,  3.7.1,  5.1. 8.  8.1. C. 
’.4.8,  11.1] 

if:?*, 

3.7.3. A] 

3.7.A.  3.7.3.A] 

3.7.2,  4.3. A] 

13.4.81 

10.1.  A] 

5.3. A] 

10. 1.1.  A] 


7.1.81 
3.7.1! 
3.6.  A] 


3. 5.1. A] 
4.1.1] 
x12.3.A] 
£12.1. 8] 
‘3.2.C] 
3.8.8] 
8.4,  8.10, 
8. 

2. 


I.1.CJ 
1.8.  A] 
10.1.9 


10.1.1.8] 


1-8] 

•  1  ■  A] 


ao_nonw_o:NAME_S 
oo_nomo_voM :  NAME  VOW 

ao_o6|oe<_4af:OSJEc!_OEF 

0_40f :  PACKAGE_OEF 
—  ooooc  0 :  PARAM_ASSOC_S 
0_«:PAfiAM_5 
*_»:  PRAGMA_8 
•RANGE 
oo_rongo_voM :  RANGE  VOW 
oo_rooorO :  INNER_REC5R0 

-  ‘  o_o:8ELECT_CLAUSE_S 


10. 

8.7. 

5.1.  A] 

3.7.3. A] 

4.4.8] 

3.3.2. 8.  3.6.8,  3.7.1,  3.7.3.A, 
4.1.1,  4.1.2.  4.1.3,  4.1.4,  4.6, 
4.7.  6.2,  5.8,  6.1.C,  6.4,  7.4. B, 
8.5,  8.5.8,  9.5. C,  10.2.A,  12.3.A. 
13.3,  13.4.A,  13.4.B,  13.5,  13.8] 
[9. 10] 

[5.7,  6.1.8,  11.3] 

[3.2.A,  3.7.1] 

[7.1.  A] 

[2.8.A,  6.4,  9.5.8] 

[6.1.8,  9.5. A.  9.5.C] 

(10.1.8,  13.4.A] 

[3.5.4,  13.4.8] 

3.5.9] 


[3.5.7,  3. 
[3. 7.3. A] 


oo_otm:STM 
oo_obw_ol :  8TM_S 
oo_otm_o2:  STM  5 
oo_ofn»_o:  8TM_S 


ao_oubpoogrom_dof:  SU8PR0QRAM_0EF 
57 

oo.oubowltboay :  8U8UNfT_B0PT 
ao_tookj6M :  TASK  DBF 
oo_1ype_range :  TfpE  RANGE 
•o.lypoopoo :  TYPEjPEC 
oo_uoR  Tbody:  UNIT JbOOT 
oo_vortont_« :  VA«ANT_3 


19. 7.1.  A] 

5.1.8,  5.5.A] 
9.7.2,  9.7.3] 
9.7.2,  9.7.3] 
5.3.A,  5.4,  5. 5. A, 
9. 7.1. A,  9. 7. 1.8] 


5.6,  9.5. C, 


[10. 2. A] 

(9.1.  Al 
[4.4.8] 

[3. 2. A,  3.3.1. A] 
[10.1.  B] 

(3. 7. 3.  A] 


34, 

70 

85 

54 

53 

78 

43 

41. 

42. 
75 
88 
53 
68 
62 

42 
40 
37 
46 
73 
72 
36 

44 
64, 
58 
33 
68 
67 
51 

43 
48 
36. 
50. 
64, 


68 

56, 

34, 

62 

33. 

58. 

SB. 

38. 

39 

43 

67 
51, 

88 

68 

53, 

t«. 

70 


54. 


36.  42.  51.  98,  63. 


43 

47 


68.  70 


40.  42.  43,  46.  47, 

52.  56,  SO,  61.  63. 

66,  70,  73.  74.  75 


58.  71 
42 

61,  66 
66 

74 

75 


54 


54,  56,  85,  67 
1.A] 


35 


VI.  a.  Lexical  Attributes 

Lexical  attributes  represent  information  provided  by  the  lexical  analysis  phase. 


[2.8.A,  3.2.A,  3.2.8,  3.2.C, 
3.3.1. A,  3.3.2. A,  3.3.2.B,  3.4, 
3.5.  3. 5.1. A.  3.5.1. 8.  3.5.4. 


33.  34,  36,  36,  37,  38, 
38,  40,  41,  42.  43.  44, 
46,  48,  47,  48.  48.  80, 


I 


tz 
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bt_numr«p:  numb*r_rap 
lx _pr»tlx:Boolaan 
bc_arepos:  aouroa_poattion 


tx_«ymr*p:  aymbol_rap 


3.8.7,  3.8.9,  3.6.A,  3.6. B,  3.7.A, 

3.7. B,  3.7.1,  3.7.2,  3.7.3.A, 
3.7.3.B,  3.8,  3.9. B,  4.1. A.  4.1.1, 

4.1.2,  4.1.3,  4.1.4,  4. 3. A,  4.3.B, 

4.4.  A,  4.4.B,  4.4. D,  4.6,  4.7,  4.8, 

8.1.  A,  8.1. B,  8.1. F,  8.2,  S.3.A, 

8.4,  8. 8. A,  8.8.B,  8.6,  8.7,  8.8, 
8.9,  6.1. A,  6.1.B,  6.1.C,  6.3,  6.4, 

7.1.  A,  7.1. B,  7.1.C,  7.4.A,  7.4.B, 
8.4,  8.8,  9.1. A,  9.1. B,  9.8.A, 

9.8.  B,  9.8.C,  9.6,  9.7.1. A, 

9.7. 1.8,  9.10,  9.7.2,  9.7.3, 

10. 1.1.  A,  10.1.A,  10.1. B,  10.1. 1.B, 

10.2, A,  10.2. B,  11.1,  11.3,  12.1. A, 

12.1 . B,  12.1 .C,  12.1.D,  12. 3. A, 

13.3,  13. 4. A,  13.4.B,  13.8,  13.8] 


[6.1.C] 

[4.4.0] 

[6.4] 

[2.8.A,  3.2.A,  3.2.B,  3.2. C, 

3. 3.1.  A,  3.3.2.A,  3.3.2.B,  3.4, 

3.8,  3.8.1. A,  3.8. 1.B,  3.8.4, 

3.8.7,  3.8.9.  3. 6. A.  3.6.B,  3.7.A, 

3.7. B.  3.7.1,  3.7.2,  3.7.3.A, 
3.7.3.B,  3.8,  3.9.B,  4.1. A.  4.1.1, 

4.1.2,  4.1.3,  4.1.4,  4. 3. A,  4.3. B, 

4.4.  A,  4.4.B,  4.4.0,  4.6,  4.7,  4.8, 

8.1.  A,  S.1.B,  5.1.F,  8.2,  8.3.A, 

8.4,  5. 8. A,  5.5. B,  5.6,  5.7,  5.8, 

5.9,  6.1. A,  6.1.B,  6.1.C,  6.3,  6.4, 

7.1.  A,  7.1.B,  7.1. C,  7.4. A,  7.4. B. 

8.4,  8.5,  9.1. A,  9.1.B,  9.5.A. 

9.5.  B,  9.5.C,  9.6,  9.7.1. A. 

9.7.1. B,  9.10,  9.7.2,  9.7.3. 

10. 1.1.  A,  10.1. A.  10.1. B,  10.1.1.B, 

10.2. A,  10.2. B.  11.1,  11.3,  12.1. A. 

12.1.  B.  12.1. C,  12.1.0,  12.3.A. 

13.3,  13. 4. A,  13.4.B,  13.5,  13.8] 
[3.2.A.  3.2.B,  3.3. 1 .A,  3.3.2.A, 

3.5.1.  B,  3.7.B,  3.7.1,  4.1. A, 

4.4.0,  5.1.B,  5.5.A,  5.5. B,  6.1. A. 

6.1. C,  7.1. A,  7.4.A,  9.1. B,  9. 5. A, 

11.1.  12.1. A,  App.  I] 


51, 

82, 

83. 

84, 

88. 

86. 

57, 

86. 

88, 

80, 

61. 

62. 

63, 

64, 

68, 

66. 

67. 

68. 

68, 

70, 

71, 

72, 

78, 

74. 

78 

59 


61 


33. 

34. 

36. 

36. 

37. 

38. 

39. 

40. 

41. 

42. 

43, 

44, 

46. 

46. 

47. 

48, 

48, 

80. 

51. 

52. 

S3. 

64, 

86. 

96, 

57. 

56. 

69. 

60, 

61, 

62. 

63. 

64, 

66. 

66, 

67, 

68, 

69. 

70. 

71. 

72. 

73, 

74. 

75 


34. 

35. 

36. 

38. 

41. 

42, 

45. 

49. 

51. 

54. 

55. 

57, 

59. 

71. 

62. 

76 

63. 

68. 

66, 

70. 

VI.  3.  Semantic  Attributes 


Semantic  attributes  represent  the  result  of  semantic  analysis  and  provide 
information  on  the  meaning  of  the  program  represented  by  the  Diana  tree. 


dafta:  Rational 

- «:  EXP  VCXO 

i_baea>_typo:  TYK.aPec 
am_btta:  Inteoor 
am_body:  BLOCK  STUB  VOIO 
anybody:  PACK_B00YjBeSC 
MN.body;  8U0P_BOOY_DC8C 
am_oomp_sp*c :  COMP  RCP_VOIO 
«w_oonatrafc* :  CONSTRAINT 


9.1. A,  9.5.A] 

3.5.4,  3.5.7,  3.5.9] 


«R_6M|_a:0CCL_8 
am_«Mn:  OCP.OO&UWttDWC 

ma:oecm<iT_vAP_8 
mr:etcepf1bN_6)EF 
—  .spec 


am_flrat:  0eP_00CUWBCMCe 


[3.4,  3.8.9] 

[3.2.A,  7.1. A, 

3.3.2.B,  3.5, 

3.5.8] 

9.1.  A,  9.1.8.  12.1. A] 

7.1.  At 

6.1.  A] 

. 3.7.B,  3.7.1] 

{3.3.2.B,  4.1.2.  4.3.A,  4.4.0] 

3.4,  3.8] 

12.3.A] 

4.1.  A] 

3.7.A,  7.4.A] 

11.1J 

4.1.  A,  4.1.1,  4.1.2,  4.1.3,  4.1.4, 
4.3. A,  4,4. A,  4.4.B,  4.4.0,  4.6, 
4.7,  4.6,  6.4] 

(3.2.A,  3.3.1.A,  3.7.1,  S.1.A, 

8.1. C,  7.1. A,  9.1.B,  12.1. A] 
)_a:OCNeiWLPAAAM  8 


37. 

38 

34. 

62. 

66. 

36, 

38 

37. 

38. 

68. 

62 

87 

71 

41, 

42 

38, 

46. 

47, 

37, 

73 

48 

44 

41. 

70 

63 

48, 

81 

46, 

47, 

34, 

36. 

42. 

68. 

71 

48,  48,  90, 


87,  89.  62. 
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12.1.  A] 

71 

am_ii>it_exp:EXP 

3.2B] 

35 

am_ln4_Mp:  EXP_VOIO 

3.7.B,  3.7.1,  6.1. C] 

41. 

42, 

se 

am_k>catk>n :  LOCAtlON 

.6.1.  A] 

57 

sm_normaHzed  oomp_s:  EXP  S 

’3.7.2,  4.3.A] 

42. 
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7.1.  A] 

62 

am  atm:  LOOP 

5.7] 

56 

sm_stm:STM 

5.1.B,  5.5. A] 

51. 

54 

am_storage  size:  EXP  ¥0® 

3.4,  3.8,  9.1. A] 

37. 

44. 

65 

am  stub:D&  OCCURENCE 

6.1. A,  7.1. A,  9.1.B, 

12.1.  A] 

57. 

62, 

65. 

71 

sm_ type  spec :  CONSTRAINED 
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VI.  4.  Cod*  Attributes 


Code  attributes  provide  target-machine-specific  Information. 


«*_""»*_**• : Intmgmr  [3.3.2. B.  3.4,  3.5. 1. A,  3.5.4.  36.  37,  38,  39 
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